В январе 2018 года исследователи Google раскрыли в публичном доступе информацию о фундаментальной аппаратной уязвимости в большинстве современных процессоров, имеющих спекулятивное выполнение команд. Уязвимость Spectre (и смежная Meltdown) эксплуатирует механизм предсказания ветвлений в CPU и позволяет проводить чтение данных через сторонний канал в виде общей иерархии кэш-памяти. Другими словами, любое приложение на компьютере может получить доступ на чтение к произвольным местам памяти, что нарушает изоляцию программ, провоцирует утечку данных, отказ в обслуживании и прочие неприятности.Хуже всего, что уязвимости подвержены практически все современные процессоры (кроме RISC и российского «Эльбруса»), потому что предсказание ветвлений стало фундаментальной частью архитектуры современных CPU, от которой невозможно отказаться без значительной потери производительности.
На самом деле исследователи нашли уязвимость ещё в середине 2017 года, просто о ней не сообщали широкой публике, чтобы у производителей процессоров и систем была возможность подготовить обновления микрокода и программного обеспечения.
Поэтому сразу после официального анонса в первых числах января Intel выпустила обновление микрокода для большого числа актуальных и устаревших моделей процессоров. Обновление доступно в виде пакетов для Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS, Fedora, Ubuntu, Debian и Chrome OS, позволяющих обновить микрокод без обновления BIOS. Обновление микрокода не отменяет необходимости применения KPTI-патчей к ядру Linux. Правда, первые версии Линус Торвальдс назвал «абсолютнейшим мусором», а Intel попросила прекратить их установку, а потом перевыпустила.
Обновления выпустили другие производители для своих продуктов, соответствующие патчи вышли для большинства операционных систем. Не избежал приключений патч для Windows 10: компания Microsoft выпустила его, отозвала, потом выпустила снова.
Но после всех этих приключений история вроде закончилась: вышли стабильные версии патчей и все, кто хотел, их установил. Казалось бы, на этом можно поставить точку. Но нет. Спустя год, 14 февраля 2019 года, группа исследователей из Google опубликовала отчёт с говорящим названием «Spectre останется с нами. Анализ атак по сторонним каналам и спекулятивного исполнения». Исследователи пришли к выводу, что только программными патчами полностью закрыть уязвимость невозможно. Для этого потребуется «значительная переработка процессоров».
Из отчёта можно сделать вывод, что уязвимость действительно фундаментальная. Авторы пишут, что все процессоры со спекулятивным выполнением всегда будут подвержены различным атакам боковых каналов, несмотря на методы частичной защиты, которое могут быть реализованы в будущем.
В отчёте сказано: «Мы считаем, что на современном оборудовании спекулятивные уязвимости подрывают конфиденциальность, реализованную на программном уровне. При этом не существует комплексной программной защиты, поскольку мы обнаружили, что зловредный код может создать универсальный механизм чтения всей памяти в том же адресном пространстве через сторонние каналы».
Intel говорила, что намерена осуществить некоторые аппаратные изменения в процессорах для защиты от Spectre. Но проблема в том, что Spectre — это не просто баг. Исследователи считают, что это широкий класс уязвимостей, которые эксплуатируют механизм предсказания ветвлений. Поэтому простыми патчами тут не обойтись.
Исследователи предложили несколько потенциальных решений, а именно:
- полное отключение спекулятивного исполнения;
- снижение точности таймера;
- маскирование ветвлений (поскольку любую проверку безопасности, внедрённую в код в виде ветвления, можно обойти по самой природе предсказания ветвлений, то авторы предлагают вообще не рассматривать ветвления в проектировании механизмов безопасности).
Исследователи делают неутешительный вывод: «Наши модели, наши ментальные модели ошибочны; мы пожертвовали безопасностью ради производительности и сложности, и не знали об этом. Сейчас горькая ирония заключается в том, что для защиты требуется внедрение ещё большей сложности с помощью программных средства, большинство из которых, как мы знаем, являются неполными… Похоже, Spectre получил слишком удачное название, потому что ему суждено ещё долго нас преследовать».
Комментарии (123)
willyd
23.02.2019 02:45+1Я вот только не понимаю, почему на это исследование ушел целый год. Все было понятно и так. И эти же самые исследователи говорили, что нужно готовиться к целому классу новых уязвимостей. Короче нужно осознать и принять, что в ближайшее время будет все больше подобных атак и заплаток жертвующих производительностью.
ЗЫ В какой-то мере, это может даже помочь. Уж больно современный софт прожорливым стал.SergeyMax
23.02.2019 10:20в ближайшее время будет все больше подобных атак
А эти «атаки» вообще были?
powerman
23.02.2019 15:57Даже если и нет — то будут. Использовать эти уязвимости не очень просто, и потребуется время и ресурсы на то, чтобы создать эффективные эксплойты. Если сейчас атаки традиционным способом (через уязвимости софта) дешевле, то в эксплойт для Spectre могли особо не вкладываться. Но вот после таких новостей, когда становится понятно, что Spectre вряд ли когда-либо закроют, создание "вечного" эксплойта, который будет работать всегда и везде, и который невозможно заблокировать — вполне может стать достаточно привлекательным, чтобы вложить достаточно средств в его разработку.
willyd
23.02.2019 17:26+1Перефразирую. "… будет все больше уязвимостей, использующих данный вектор атаки,..."
А по поводу были или нет. Думаю, что в исследовательских целях был сделан не один дамп. На мой взгляд, проблема сейчас в том, что атакующему нужно знать, что искать в полученном дампе, и это сложнее чем осадить дамп памяти в каком-то кеше.
Serge3leo
23.02.2019 04:32снижение точности таймера
Как бы Intel изначально всё так и задумал, и в x86 изначально был бит отключения RDTSC для непривилегированных процессов. Конечно, его можно усложнить, скрестить с RDRAND.
Но, сдаётся мне, если сейчас базу RDTSC случайно изменять с частотой HZ (_SC_CLK_TCK), естественно, корректируя переменную смещения для системных вызовов clock_gettime()/gettimeofday(). То, если всё сделать разумно, Spectre не пройдёт ;)khim
23.02.2019 05:37+1Уже проводились исследования — можно вообще без RDTSC. Просто считать количество итераций цикла. Менее удобно и надёжно — но работает. Уж очень времена доступа к тому, что есть в кеше и к тому, чего там нет отличаются — примерно на два порядка (не двоичных, нет: L1 — это 4-5-6 тактов, оперативка — это 400-500-600 тактов)
Space__Elf
24.02.2019 06:48можно вообще без RDTSC. Просто считать количество итераций цикла. Менее удобно и надёжно — но работает
Крайне стрёмный вариант, помню как игрушки для x286 носились с бешеной скоростью на x386, а на x486 вообще становились неиграбельны. :(DistortNeo
24.02.2019 11:11+1Во-первых, это не имеет значения. Нас интересует относительная скорость, а не абсолютная.
А во-вторых, причиной описанного эффекта было банальное переполнение счётчика итераций.
kot1972
23.02.2019 09:20Очень надеюсь, что когда нибудь до разработчиков (и харда и софта) дойдет та мысль, что развитие должно идти не в сторону увеличения количества транзисторов и строк кода, а в сторону изменения примитивов разработки.
В компах 80-х годов между примитивом, то есть ячейкой памяти, регистром ввода вывода, контактом микросхемы и идеей разработчика не было никаких прослоек. То есть вот машинный код а вот нога микросхемы. Между передним фронтом (разработкой) и задним фронтом (аппаратные и программные примитивы) расстояние было минимальным. И разработку можно было полностью контролировать. И разработку можно было легко вести.
Сейчас миллиарды транзисторов невозможно полностью контролировать.
Миллиарды строк кода невозможно полностью контролировать.
Будь то 1С, будь то windows, будь то «микроядро» linux, будь то архитектура x86 или любая другая.
Когда оно (код, железо) только родилось оно мелкое, гибкое, шустрое и легкое.
Потом туда начинают напихивать всё больше и больше, и оно становится всё менее и менее контролируемым и управляемым. Потом оно просто становится неуправляемым.
Так вот когда чтото стало разбухать его надо или делить на меньшие отдельные независимые части или делать примитивы качественно другими. Растояние от примитивов до переднего фронта чрезмерно вырастает. И в итоге уже никто не в состоянии в голове уместить весь продукт.
О чем говорит например то, что ядро линупса имеет сколько там миллионов строк кода? Это говорит о том, что аппаратная часть слабая и программно реализуются те вещи, которые должны быть реализованы аппаратно. Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.
О чем говорит архитектура x86? она говорит о том, что вместо того, чтобы тратить огромное количество человеко часов на совместимость с софтом тридцатилетней давности, на слежку за пользователями и на возможность в необходимый для цру/анб/нба/фсб момент выключить пользовательский комп не спрашивая пользователя, надо выпустить новый «простой z80» качественно другого уровня, а для желающих использовать старый софт продолжить выпускать 86- 586 процессора. Благо при наличии fpga это не сложно.
В моем наивном глупом детском понимании основная беда во всех случаях одна — слишком большое расстояние от примитивов разработки до конечного продукта.DracoL1ch
23.02.2019 09:24Утопия. Сложность перекладывается с софта на железо, которое всегда и везде конкурировало намного сильнее, подвержено физическому износу и браку.
Кодите тоже без фреймворков, чтобы без примитивов?kot1972
23.02.2019 12:24+1Дело не в железе. Дело в уровне примитивов. Они сейчас слишком примитивны, они остались прежними, теми же что и в 80-х, так чтоли сказать. Я сейчас покушусь на святое, но тот же дельфи был гораздо более удобен для программирования нежели современный питон. А бейсик был ещё удобнее. Там очень многое было спрятано и не отвлекало. Или просто не существовало в силу простоты тогдашнего железа. Но кодить тогда было однозначно комфортнее.
Danik-ik
23.02.2019 16:14+3Не холивара ради. Я программирую на том самом, седьмом ещё Дельфи. С детства почти, очень профессионально, логику с интерфейсом не мешаю. Сегодня работаю, а не давным-давно работал. И мне таки неудобно. Не хватает современных, классических уже примитивов. Огромное количество нелепый телодвижений нужно, чтобы сделать, к примеру, аналог лямбда-функции. Или сделать ORM, (писал для последнего проекта) — неудобно, нету аннотаций. Без дженериков (нету их) — боль. А Вы говорите, примитивы не менялись… И даже так, "в режиме эмуляции современности", получаются системы намного более сложные в пересчёте на час рабочего времени и куда как более гибкие, чем тогда.
Бэйсик — особая история. Тот, с которого я начинал программировать, имел только глобальные переменные. Только глобальные, Карл! Переменные на стеке? Рекурсия? Не слышали… Шестнадцать лет назад щупал vb, там стало намного лучше, но классы наследовать нельзя было. Абстракция, обобщения? Тьфу на вас ещё раз, обойдётесь!
То, что я вспоминаю старое время с теплотой не говорит о том, что "сидеть под голым досом и не стыдиться" было лучше. Может, нам-тогдашним, молодым, горячим, наивным и было в кайф, я не спорю. Было, мне так точно было. Но я вырос. Я решаю насного более сложные задачи, и делаю это кратно быстрее. Я думаю об архитектуре, о трудоёмкости доработок, о читаемости кода. И в этом намного больше удовольствия! Я могу больше. Свой опыт, чужой опыт. И то, и другое часто выражено в примитивах, абстракциях. Новых примитивах, новых абстракциях. И они реально создают моё качество работы и её эффективность .
А старый, "добрый" Дельфи — я его конечно хорошо умею и очень ему благодарен, но приходится таки время от времени запускать Идею и поднимать себе настроение Джавой. Кайф, честно...
Mov_AX_0xDEAD
23.02.2019 11:00+2Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно
intel на это и напоролась, обойти аппаратную фичу не может полностьюkot1972
23.02.2019 12:01-1Ключевое слово FPGA. Там можно править аппаратную часть программно. Главное при этом то, что примитив может быть гораздо более функционален и автономен, нежели в случае миллионов
нефтистрок кода. И он отдельный. И его можно разрабатывать отдельно. И его можно отлаживать отдельно. И он может быть универсальным. Например.
Однако дело не столько в fpga, fpga скорее для примера, дело больше в том, что примитивы разработки слишком примитивны, так чтоли сказать. Был бейсик, он был прост как мычание. Нажал кнопку вкл на компе и вот он уже тут, через секунду. Попробуйте так с типоном, например. Или с пхп.Mov_AX_0xDEAD
23.02.2019 20:46Ключевое слово FPGA. Там можно править аппаратную часть программно.
будет регресс скорости, поэтому выбирают хайэнд от интел и амд вместо примитивных openrisc и т.п.
DaneSoul
23.02.2019 11:05+3Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.
Посмотрите на историю изменений этих строк — сколько раз там находились ошибки, что-то исправлялось и доделывалось.
А теперь представьте что изменение это не програмный патч, а необходимость переделывать архитектуру на низком уровне. Насколько сложней будет внедрять патчи?kot1972
23.02.2019 12:18Какие нужны трудозатраты чтобы начать программировать на бейсике на компе 80-х годов и начать программировать на php сейчас? Там кнопку вкл нажал и вот оно здесь через секунду, а сейчас? Сколько нужно времени чтобы просто получить промпт питона?
Накладные расходы на вхождение в тему сейчас стали просто огромными. Зачем они?DaneSoul
23.02.2019 12:42+2Давайте посмотрим с другой стороны.
Сколько времени потребуется программисту чтобы написать аналитическую систему комплексной стат.обработки с чтением\сохранением разных форматов данных и построением графиков\диаграмм на Бейсике 80-х годов и на современном Питоне с библиотеками?
Задачи принципиально усложнились.
Когда PHP начал распространятся 20 лет назад сайты состояли из нескольких шаблонов и нескольких форм и всё, структура страниц была проще, ни о какой динамической подгрузке, адаптации под мобильные, кучи кастомизации речи не шло.DrPass
23.02.2019 13:53Задачи принципиально усложнились.
Смотря с каким периодом сравнивать. Если брать совсем уж зарождение отрасли, то да, принципиально усложнились. Если брать чуть позже, например, уже вторую половину 1990-х, то там не было некоторых современных отраслей IT, например, BigData и Machine Learning, но на 90% решаемые задачи вполне себе соответствовали нынешним, естественно, с поправкой на окружение тех лет. Т.е. вместо веба клиент-серверные и распределенные десктопные приложения, вместо шустрых интернетов локальные сети предприятия и модемы.
Инструментарий разработки десктопных приложений в те годы был не хуже, а то и лучше, чем сейчас его аналоги для веб-приложений. При этом скорость реализации функционала, я не ошибусь, если скажу, что была заметно выше.DaneSoul
23.02.2019 14:31+1Инструментарий разработки десктопных приложений в те годы был не хуже, а то и лучше, чем сейчас его аналоги для веб-приложений.
Десктопное приложение тогда обычно разрабатывалось под конкретную операционную систему и разрешение экрана, а веб-приложение должно сейчас работать и на планшете и на телефоне и на десктопе в разных браузерах и разрешениях, к тому же права такого приложения на действия в системе существенно ограничены из соображений безопасности.
Так что учитывая кросс-платформенную поддержку и отзывчивость дизайна, сложность системы в целом тоже существенно увеличилась.DrPass
24.02.2019 16:02Да не сильно большая и разница, если честно. Тогда была другая особенность дизайна приложений — поддержка произвольного размера окна. Понятно, что не все этим заморачивались, но в целом для профессиональной, а не наколенной разработки надо было точно так же учитывать, что размер окна вашего приложения может быть любой, и соответствующим образом подстраивать интерфейс. А с браузерами наоборот, времена, когда надо было держать в уме особенности IE, Netscape и Opera, тоже позади. 80% — Blink, 20% — практически полностью совместимые с ним WebKit, Edge, Mozilla. Причем отличия на уровне «добавить ещё одну строчку в стиль, чтобы в Сафари убрать лишнее свечение дропдаунов в фокусе».
mistergrim
23.02.2019 13:49+1Сколько нужно времени чтобы просто получить промпт питона?
Да примерно столько же.
Да, с какой-нибудь IDE всё будет посложнее, но она и возможности даёт несопоставимые с тем бейсиком.
alsoijw
23.02.2019 14:15
zerg59
23.02.2019 12:17+5Я один вижу здесь взаимоисключающие параграфы?
Сейчас миллиарды транзисторов невозможно полностью контролировать
. Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно.
Какая разница, где у вас будут ошибки, если ошибки неизбежны?
Fenzales
23.02.2019 13:40+2Не должно быть миллионов строк кода. Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно.
А аппаратный код собирают по весне с чайных деревьев?
amartology
23.02.2019 17:25+2Должна быть одна тысяча строк кода а остальное должно быть реализовано аппаратно. В FPGA или ещё как — не суть важно.
Вы же в курсе, что микросхемы проектируются посредством написания кода на языке Verilog, да? )kot1972
25.02.2019 04:32-2О господи, это же филиал пикабу. Тут тебе и остряки, тут тебе и минусеры. Полный набор молодых амбициозных незнаек.
Дражайший юморист, я как раз на этом самом верилоге то и пишу. И как раз потому в тему и полез, что считаю, что нужны не количественные изменения а качественные. В частности развитие аппаратной части. И fpga для этого подходит идеально.
А начинал с трех ассемблеров и жабы. В 1990 году. И фен и паяльник умею в руках держать.
Беда в том что современные быдлокодеры умеют в миллионы строк быдлокода на пхп, в жаваскрипт фреймворках разбираются, и больше ничего.
Шаг влево шаг вправо — святотатство. Я сосбсно в этом ещё раз тут убедился.
Набежало амбициозных юмористов, умеющих в пхп, каждый пометил территорию, задрал лапку, предложить правда ничего не предложил. Но пометил.
А нечего короче тут ловить. Пикабу 2.0, реально.
NoRegrets
23.02.2019 12:02У меня та же мысль возникла при появлении spectre — почему бы не сделать менее точный таймер для прикладных приложений, а существующий оставить только для того кода, который работает в нулевом кольце? Дешево и сердито. Защита не 100%, но еще один уровень.
Если какому-нибудь аудио/видео-обработчику или другому прикладному софту требовался бы высокоточный таймер, писали бы собственный модуль ядра и работали с ним.
OnkelTem
23.02.2019 12:18-4Ребята, у меня вопрос. Может ли это как-то затронуть приложения на Google Play? Можно ли анализом .class-файлов (или что там ещё может быть внутри приложения) со 100% вероятностью предсказать наличие эксплоита Spectre?
gradmir
23.02.2019 14:07-2Теоретически это возможно. Эксплойт скорее всего будет прятаться в файлах .so, находится так же, как обычные вредоносы: на основе сигнатур. То есть, эксплойт не найти, пока информация о нём не попадёт в БД антивирусов. Берегись! Жидомасоны уже выехали за тобой.
OnkelTem
24.02.2019 05:06Ну и мразотная тут тусовочка. Просто вопрос задал и влепили 4 минуса. Идиоты…
Реально, как в говно наступил.
omikron24
23.02.2019 16:27-2Наиболее вероятен совсем другой подход. Приведу аналогию. Есть государство и преступники, в государстве нашли уязвимость которая позволяет преступникам совершать зло. Все комментаторы выше предлагают изменить государство таким образом чтобы в нём не было зла изначально, что неверотяно дорого и сложно, утопично я бы сказал. Это правильный подход с логической точки зрения, однако он практически невыполним в текущих условиях. Более практичным и дешёвым подходом будет охота на преступников.
Таким образом имеем проверку исходного кода, поиск, выявление и преследование тех, кто уязвимостями пользуется.
Для тех кто собирается комментировать про спецслужбы — в их арсенале наверняка есть как более продвинутые так и более архаичные методы получения информации, и да, то что считается незаконным для обычных граждан может быть позволено и оправдано для использованияя спецслужбами, будь то насилие, кража информации т.д. в «высших» целях. Вопрос о преследованиях политических оппонентов и всего с этим связанного находится скорее в плоскости морали и его я обсуждать не намерен.DaneSoul
23.02.2019 17:17+2Более практичным и дешёвым подходом будет охота на преступников.
И государства за тысячелетия охоты за преступниками так и не смогли полностью их искоренить.
Это по-сути задача «снаряда и брони». Чем сильней становится защита, тем изощренней находятся способы ее обойти.omikron24
23.02.2019 20:26Вот именно, никто и ничто не совершенно, я написал тоже самое про предлагаемую утопичную архитектуру. Однако в некоторых государствах удалось добиться очень низкой преступности, благодаря нормальной работе правоохранительных органов.
Мой комментарий не о нахождении новых уязвимостей, он об использовании уязвимостей как таковых, это ведь осознанный выбор.
Pasha4ur
23.02.2019 21:59По-адекватному стоило бы снизить цены на текущие и прошлые поколения процессоров Интел. И разрабатывать новые.
По сути продают процессоры с вечной дырой в защите.
Не зря по слухам Эпл уходит на RISC
Londoner
24.02.2019 00:33А можно просто выключить спекулятивное выполнение? Для многих задач, если производительность упадёт раза в два, а не в тысячу, но при этом такие атаки будут исключены, то и ладно.
А если производительность проседает сильно, нельзя ли просто ввести команды выключения-включения спекулятивного выполнения, чтоб код, который отвечает за что-то критичное по безопасности, отключал спекулятивное выполнение, а потом его снова восстанавливал?DistortNeo
24.02.2019 11:21Скорее, имеет смысл добавить новый бит «не использовать для спекулятивного выполнения» к флагам страниц памяти, чтобы защищать данные. Сейчас же есть только бит — «не кэшировать».
Londoner
24.02.2019 15:17Кстати, да, бит «не кэшировать страницу» разве не спасёт хотя бы частично?
DistortNeo
24.02.2019 15:25Нет, это не помешает спекулятивно загрузить из этой страницы данные.
А вот замедлить код на пару порядков — может.
khim
24.02.2019 15:19А можно просто выключить спекулятивное выполнение? Для многих задач, если производительность упадёт раза в два, а не в тысячу, но при этом такие атаки будут исключены, то и ладно.
Там разница раз в десять будет. Современные процессоры делают очень много разных спекуляций на разных уровнях. Если из выключить все — будет очень больно.
Zarathu5trA
24.02.2019 09:13Божечки ж ты мой.
Тезис N1: Spectre (S) и Meltdown (M) являются прямым следствием роста сложности реализаций процессоров. Современный ЦПУ обладает сумасшедшим уровнем сложности. В частности, SM-уязвимость возникает на стыке казалось бы независимых компонентов: предсказание ветвлений, спекулятивное выполнение, кэширование, механизмы организации безопасности, механизмы организации адресных пространств. Их можно закрыть аппаратно. Но! Очень сложно гарантировать отсутствие подобных уязвимостей при сохранении текущего уровня сложности ЦПУ.
Тезис N2: Уязвимости типа SM можно закрыть программно на уровне ОС. SM дает возможность читать из той части адресного пространтства текущего процесса, которая принадлежит ядру. Соответственно, нужно сделать так, чтобы в этой части адресного пространтства не было критически важной информации. Соответственно:
Вариант а) Микроядро в основе системы. В истинных микроядрах в пространстве ядра нет ничего интересного для чтения вредоносом. Все что интересно, находится в адресных пространствах ДРУГИХ процессов, куда нужно сначала переключится. Так что туда с помощью SM не залезть
Вариант б) Для Linux-подобных систем. Ядро выгружается в свое отдельное виртуальное адресное пространство (свой процесс). В пользовательских процессах остается только заглушка, которая по системному вызову (прерыванию) производит переход в виртуальное адресное пространство ядра и передает туда же управление. Опять же, прощай SM.
Так что закрыть SM чисто программно можно на уровне ОС. НО! Это не дешево! Потери производительности будут значительными! Стоимость холосного системного вызова выростет как минимум в 5-10 раз. И на это еще наложится трэшшинг кэша и TLB. Так что совокупные потери производительности могут легко дойти до величин в районе в два раза.
gnomeby
24.02.2019 11:57кроме RISC и российского «Эльбруса»
1. ARM — RISC и он частично подвержен Spectre
2. У Эльбруса нет предсказателя переходов и он действительно не подвержен большому классу уязвимостей. Тем не менее теоритически он может быть подержен сходим уязвимостям.
NeoCode
Хороший повод похоронить древнюю и кривую архитектуру x86 с кучей legacy и перейти на что-то более современное, разработанное с нуля и с учетом потребностей современного мира. Только что-то не верится что это случится…
powerman
Если найдут ещё несколько аналогичных уязвимостей, патчи для которых угробят производительность не на 15%, а на 200% — тогда это вполне станет возможным.
DracoL1ch
Сколько лет и денег потребует она? Каков потенциальный доход? Сколько маркетинга потребуется, чтобы вытряхнуть пользователей из старого? Есть причины, почему этим никто не занимается.
imanushin
Возможно, стоимость разработки будет сопоставима с бюджетом фильмов Матрица 2/3 ($300 млн).
Beyondtheclouds
300 лямов это такое копье что даже смешно)(у интела на R&D в 17 году бюджет 13 лярдов) там нереальное количество денег придется вбухать всему it сектору на переход. и в разработку чтобы получилось сопоставимо по качетсву/сложности.
imanushin
Кстати, а Вы не знаете, сколько стоила разработка процессоров Эльбрус и Байкал?
AllexIn
Что такое разработка?
Не знаю про Эльбрус(слишком уж мифическое существо), но для Байкала архитектуру не разрабатывали, а лицензировали.
naneri
А ещё толпу софта переписать под новую архитектуру.
AllexIn
В современном мире это уже не проблема. Подавляющее большинство современных фреймворков кроссплатформенные. А для legacy можно делать эмуляцию.
zartarn
Корпоративный сегмент очень «любит» и эмуляцию. и виртуализацию, особенно всякие вещи с шифрованием и т.д.
Данный рынок слишком энертный для таких подвижек.
AllexIn
Те кто связаны с шифрованием — первым делом убегут на другие архитектуры.
zartarn
Они на другую ось то убежать в корпоративной среде не могут. а вы говорите про другую архитектуру.
khim
Подавляющее большинство современных фреймворков кросс-платформенные и использовать из на медленных процессорах без спекулятивного исполнения невозможно.
Потому и развелось в последнее время столько «кроссплатформенных» фреймворков, что все архитекуты стали похожими, как близнецы… вот только и уязвимости у них — тоже похожие…
Речь же не идёт о том, чтобы перекомпилировать что-то. Нужно перепиcывать. Под совсем-совсем другую парадигму.
AllexIn
Нет не нужно.
Требования к предсказанию условных переходов есть у свежего ресурсозатратного софта.
Древний софт написанный 5-10-15 лет назад на современных процах будет работать вполне нормально в режиме эмуляции без всяких предсказаний.
А свежий ресурсозатратный… Ну это сильно специфичная штука, и надо конкретные примеры смотреть.
Браузеры конечно очень пострадают и игры. Это основные массовые проги которые пострадают от выключения предсказаний.
Всё не массовое можно запускать в закрытых экосистемах. Где левого опасного софта нет.
Если уж на то пошло, мне не понятно, почему не сделать отдельное ядро без предсказаний на котором вертится весь не доверенный софт и отдельно ядра мощные с предсказаниями, но доступ к которым есть у ограниченного количества софта. Может это обсуждалось и я просто пропустил?
DistortNeo
Вы думаете не в ту сторону. Угроза эта, в первую очередь, не для потребительского сегмента, а для дата-центров.
YetAnotherSlava
Да сколько бы ни потребовала, это лучше, чем писать очередной, 100500ый по счёту JS фреймворк, и создавать 100501ый по счёту стартап по уберизации работы слесарей, или обработке фото, или чему-то столь же полезному.
Можно конечно возразить: «Откуда возьмутся деньги? Кто это оплатит?», отвечу заранее — вот вы, граждане, и оплатите. И сейчас вы платите, и потом будете платить. Сейчас вы оплачиваете ипотеку (за бетонную конуру) и автокредит отечественному банку, банк отдаёт заёмные средства другому банку, а тот, в свою очередь, переводит очередной многомиллиардный транш, сбрасывая с вертолёта мешок с деньгами для очередного единорога из золотозвончатой долины, делающему убероподобный трэш с котиками и блокчейном. Политика у инвесторов такая — переводить деньги на всяческую ерунду. Чтобы гарантированно ничего полезного не выросло. Достаточно лишь изменить политику
Pydeg
Что, простите? У них политика как раз обратная. Или у вас все ерунда, что лично вам не нужно?
timdorohin
У инвесторов политика — отбить деньги, чем быстрее, тем лучше.
Однажды до них дошло, что вместо инвестиций в многолетние разработки и выпуск качественного продукта можно делать дерьмо, потратив большую часть денег на пиар и убеждение хомячков в огромной нужности продукта, чем серьезно сократить время окупаемости.
Так и живем.
engine9
Ох воу. Чтобы люди были рационалистами их нужно с детства так воспитывать, прокачивая логическое мышление, стратегическое видение и научный подход. Только тогда рухнет к черту
копроэкономика.dimka11
Были слухи, что Apple откажется от x86 в пользу своих процессоров.
Koneru
Нет абсолютно никакой гарантии что в новой архитектуре не будет уязвимостей такого уровня.
imanushin
Например, архитектура VLIW переносит задачу планирования параллельного выполнения соседних команд на компилятор. А последний знает больше о коде, чем процессор, потому может более вольно менять порядок инструкций.
В итоге получаем отсутсвие предсказателя перехода и увеличение вычислительных модулей.
Конечно, вероятность абстрактной уязвимости ненулевая, однако она ниже. Ибо меньше скрытых сложнодетерменированных блоков.
khim
Потому производительность VLIW-процессоров в однопоточных программах и близко не приближается к производительности суперскаляров.
А вот если бы мы могли освоить многопоточность «по настоящему» (не 2-3-4 потока, а сотни потоков, которые программы могли бы эффективно использовать) — то всё можно было бы сделать сильно по-другому… но тут нужно переписывать не одну-две программы, а вообще всё, что за десятелетия наработали… тут бюджетами в сотни миллиардов не отделаться…
vladkorotnev
Про предсказывание частоты срабатывания сразу вспомнилось, как на Z80 старались выбирать между операторами JP / JR, потому что JP выполняется за постоянное время в 10 тактов, а JR при несрабатывании условия за 12, но при срабатывании всего лишь за 7.
Так что может быть тут тоже всё решится в итоге перекидыванием ответственности на разработчика, пишущего вместо привычного условия что-то типа
if ( myVar == 10 :likely(true) && theirVar > 20 :likely(false) ) {?khim
Пробовали. Во времена Pentium4. Не работает. Разработчики слишком часто ошибаются. Уж не говоря о том, что мало кто знает о том, что эта фишка уже существует — но на практике я только в ядре Линукса видел её использование…
TrueBers
Да не скажите, что мало где используется. Вижу довольно часто. К тому же, как бы уже почти стандарт.
beeruser
Процессоров общего назначения с branch hints уже никто не делает. Потому что это стало бессмысленно. Современный предсказатель не только лучше отработает, но и сможет адаптироваться к изменению поведения программы. Хотя конечно компилятор может положить код так, чтобы оптимизировать fetch.
Раньше я и сам использовал __builtin_expect() там, где это могло помочь — на in-order PowerPC.
timdorohin
Вы сей комментарий пишете из программы собранной с PGO
Так вот, к вашему сведению — PGO это и есть механизм, позволяющий компилятору не гадать, а знать, что, куда и сколько ходит по переходам.
Итаник потонул по многим причинам, но это не значит что заложенные в нем идеи — плохи.
Маркетинг, бессмысленный и беспощадный, как и сама x86…
DistortNeo
Пруфы?
PGO плох тем, что:
Использует апостерионую информацию. Компилятор не знает ничего о переходах, пока не будет сделано профилирование кода. А это довольно долгий и ответственный процесс.
Предсказания становятся захардкожены. Если в реальном сценарии использования программы статистика переходов будет другой, то получим падение производительности.
Аппаратный предсказатель же позволяет упростить компилятор, упростить систему команд и добавить гибкости в процессе работы программы.
timdorohin
Официальные билды Firefox и Chrome (а так же большинства производных браузеров) идут с PGO. Edge — вероятно, но не знаю точно.
Если вы изощренный маргинал, я пролетаю мимо.
Да, это хуже чем предсказатель переходов. Но много лучше, чем вообще без ничего.
khim
А если алгоритм параллелится хорошо, то он, с вероятностью 99%, хорошо ложится и на GPU — и Итаник снова «не при делах».
Просто неправильно была проведена изначальная оценка: считалось, что Итаниум будет хорошо себя вести на 90% задач, а оказалось — что на 10%, в лучшем случае…
timdorohin
И тем не менее Intel Core жрут до 4 инструкций за такт, и интел обещает сделать до 5 у Sunny Cove, подняв этим производительность. Просто так бы такое не делали.
Кстати, 2-3 за такт это для CISC, RISC это 3-5 для хорошего суперскаляра, а в случае MISC/микрокода до десяти доходит.
khim
Это всё равно не моможет VLIW'у. Ему важно не до скольки оно «доходит», а до скольки оно «опускается». Если можете выдержать 3 инструкции на такт устрйчиво — молодец, VLIW уже может бороться с суперскаляром, сможете устойчиво сделать 6 — и суперскаляр будет «плакать в сторонке».
Но… не получилось. «Не шмогли» разработчики компиляторов это сделать для «типичного кода». А для «нетипичного» — для него GPU, TPU и прочие «модные штучки» есть…
Это, кстати, суперскаляр против VLIW только. Если же у нас есть спекулятивные исполнения — то всё ещё хуже: один промах мимо кеша — отправляет процессор «в аут» не на одну сотню тактов. Если спекуляции у нас есть — мы можем в это время заняться тем, что должно бы случится после того, как эти данные «подвезут» (и выполнить пусть не сотни — но как минимум десятки команд спекулятивно), если спекуляций нет — всё, приплыли… ждать — и без вариантов…
timdorohin
Не стоит грести все VLIW под одну гребенку.
Многие считают что VLIW отменяет необходимость в декодере инструкций. Это не так. Кодовые слова произвольной длины резко убирают все «дыры» в кешах, повышая плотность кода, и при этом не требуют особо сложной схемотехники.Опять же, не обязательно. Barrel-архитектура с пропуском застрявших потоков исполнения, и общий для всех потоков конвейер (а VLIW не обязывает процессор не иметь конвеер вообще, к слову) может серьезно так поднять производительность. При этом, без логики предсказывающей переходы и внеочередного исполнения.UPD: Только сейчас дошло, что вы о производительности одного потока с исключительно последовательно выполняемыми командами. В подобном случае и внеочередное исполнение мало поможет, если каждая последующая инструкция зависит от предыдущей.
Akon32
Насколько я понимаю, для VLIW нужно компилировать свой бинарник под каждую модель процессора, если есть какие-то отличия в числе исполнительных устройств. Очень "хрупкая" архитектура.
X86 в этом отношении весьма неплох — в одном и том же коде разные процессоры по-своему распределяют инструкции по своим исполнительным устройствам. Хотя это аппаратно сложнее, а значит медленнее и прожорливее.
imanushin
Тут очень тонкий момент. VLIW можно представить как более низкоуровневый процессор, где убрали предсказатели перехода и позволили сделать параллельное выполнение соседних команд. Т.е. говоря другими словами: предсказания перехода ушли из процессора, то есть уязвимости типа Spectre не могут там появиться архитектурно. Последнее важно, так как на тех же ARM/x86 от уязвимостей не уйти просто потому, что есть предсказатель этих самых переходов.
Далее: по сравнению с серединой нулевых, сейчас намного больше программ, которые не компилируются сразу в машинный код. То есть в программах на Java/.Net/Python/JS не придется менять ничего, кроме native кода. Более того, даже компиляция зачастую работает через LLVM (кстати, через него работает Kotlin Native и .Net Core). Или другими словами: по сравнению с 2005 годом не придется перекомпилировать столько ПО. Придется лишь серьезно обновить не такой большой набор технологий.
Однако и тут всё стало проще. Всё дело в том, что аналог предсказателя переходов есть в той же Java. В процессе работы программы она замеряет "горячие точки" и переставляет иструкции и т.д. Причем, что очень круто, та же Java может позволить себе намного больше вольностей, по сравнению с аналогичным модулем на процессоре.
Однако, чтобы подытожить текст выше:
MacIn
Можно добавить слой абстракции для не time-critical кода, скажем, микропрограммную прослойку, с прямым доступом к самому VLIW там, где требуется. Значительная часть кода, которой не нужна большая производительность, но нужна переносимость, будет работать на разных моделях.
Paskin
Да — например, у современных DL-ускорителей нужно компилировать (или как они называют — «оптимизировать») код под каждый тип отдельно, а полученный бинарник не работает даже на следующей версии от того же производителя.
beeruser
Не может. А вот OoO процессор может переупорядочивать чтения и записи в память, выполнять код без остановки, когда предыдущие инструкции ещё ждут данных.
А куда он денется? Есть конвейер — нужен и предсказатель (если не хотим столлы на каждом бранче).
imanushin
Да нужен, однако я говорю, что сейчас эту задачу может взять на себя прикладное ПО. И это было намного сложнее 10 лет назад.
Задам еще вопрос: в чем принципиальный плюс встроенного предсказателя переходов в чип? Почему его нельзя поместить в ту же JVM/CLR/LLVM ?
Crazybunter
Конечно, от 0day не убежишь
khim
С учётом того, что Spectre влияет на ARM, POWER, RISC-V — а и вообще на любые процессоры, которые поддерживают спекулятивное исполнение неясно на что предлагается переходить.
По хорошему-то нужно научиться писать так, чтобы программы могли исполняться на сотнях (а в перспективе — и на тысячах) медленных ядер, но… это ж не x86 придётся похоронить, это придётся терабайты уже написанного кода похоронить — кто это может себе позволить?
Serge3leo
Хм. Ну зачем же систему команд менять? Да даже и спекулятивное выполнение не обязательно выкидывать.
Например, каждой странице назначаем ключ/маску, в результате разные процессы будут видеть память по разному. И потребуется изменить только ОС, причём в сравнительно небольших объёмах.
khim
Слишком много в процессоре разных буферов, кешей и прочего, на которые оно может повлиять. И архитектура команд процессора — тут вообще дело 10е.
Если бы. Чтобы «следов» не оставалось потребуется при каждом системном вызове все спекуляции и, главное, все буфера, где спекуляции могут «насладиться» сбрасывать. Это радикально изменит весь дизайн ОС. Потому что сделает системные вызовы баснословно дорогими — а это, как бы, полная противоположность тому, что есть сейчас и под что весь существующий софт заточен…
Serge3leo
Э-э-э. Если немного изменим процессор. Есть у в них такой модуль, который занимается кодированием и исправлением ошибок ОЗУ, таким образом что бы каждый пользовательский процесс будет читать данные обработанные уникальным ключом/маской, например, на каждую страницу памяти. То спекулятивное исполнение можно оставить ;)
khim
Причём тут вообще ОЗУ? «Следы» остаются не в ОЗУ, а в многочисленных буферах внутри процессора. И либо вы их чистите при переходе в ядро и обратно, либо нет. Если вы их чистите, то «цена» системных вызовов возрастает на пару порядков (то есть замедление не на 10-15%, как современные патчи делают, а в 10-100 раз), а если не чистите — то всё сводится к тому, как именно злоумышленник заставит CPU поместить результат спекулятивного исполнения именно в ту часть процессора, которую вы решили не прочищать.
Может быть сработает простой трюк: выключить вообще всякие спекуляции при исполнении кода ядра — тогда замедление скорости работы ядра будет многократным, но, возможно, терпимым.
Остальное — паллиатив…
Serge3leo
Ещё раз, чистить не обязательно, изменяем процессор так, что каждый процесс ОС видит данные по конкретному физическому адресу разные, везде разные, во всех кэшах, и всё. Процесс, которые что-то выясняет с помощью спекулятивного выполнения, выяснит нечто своё, ну и Бог с ним.
Для чувствительных данных (ключи, пароли), даже сейчас, без аппаратной поддержки, возможна программная защита (данные под маской/ключом, маска/ключ достаточно часто меняется). В принципе, полностью аналогичная обычным методам защиты от утечки по побочным каналам.
khim
В том-то и дело, что поскольку разные участки памяти с неизбежностью мапятся на одно место в кеше — то он сможет выяснить не «что-то своё», а «что-то про все участки памяти, замапленные в это же место».
Добиться того, чтобы этого не происходило можно только одним способом — выделив каждом процессу своё ядро… но даже этого не хватит! Потому что останется ещё операционная система, которая тоже выполняется на процессоре со спекулятивным исполнением и которую тоже можно использовать для передачи данных.
Вот если сделать так, чтобы операционка выполнялась на процессоре без спекулятивного исполнения и вдобавок к этому, ещё и все процессор выполнялись на разных физических ядрах (или полностью сбрасывать все кеши при переходе от одного процесса к другому, что, фактически, то же самое)… тогда, возможно утечек удастся избежать.
Очень-очень сложно. Вы знаете как ключ для XBox360 находят? Уникальный, прошитый в процессор, никогда не выдаваемый наружу? Замером скорости функции memcmp. В прошивке, начиная с какой-то версии вместо memcmp используется посимвольное сравениение всех 16 байтов с занесением результата в 16 байн на выходе, потом их все or'ят и только потом сравнивают с нулём. Но это вы всё можете проделать только если на ассемблере пишите, а если у вас оптимизирующий компилятор — то всегда есть шанс, что он поймёт, что вся эта машинерия эквивалентна memcpy и вернёт её взад!
Serge3leo
Ну, как, как? Данные из кэшей попадая в процессор модифицируются исходя из TLB и/или регистра состояния данного процесса, а ля кодов хэмминга, уникальным для каждого процесса образом. Таким образом спекулятивное выполнение другого процесса будет отличаться, т.к. для него будут приходить иные данные в процессор.
А это ничего, что всё прогрессивное человечество уже многие годы как придумало и использует memset_s()/explicit_bzero()/SecureZeroMemory()?Но это для халявщиков, которым наплевать на побочные каналы, а при строгой смене масок/ключей, компилятор не может может вмешаться.
khim
То есть, в частности, разделяемые библиотеки перестанут быть разделяемыми? Чуть лучше, чем полный сброс всего, но тут мы упираемся в необходимость хорошо всё рандомизировать. У L1 и без того задержки изрядные.
И по прежнему остаётся возможность использовать ядро для передачи информации…
Кто ему запретит?
Serge3leo
Это ж вряд ли. Хотя и зависит от организации конкретного ядра.
Как бы когда пишут константы и/или освобождают память, у компилятора ручки свободны. А когда меняют ключи/маски у компилятора соблазна нет, данные реально изменяются, кроме того эти изменения независимо контролируются и потенциальные ошибки компилятора будут обнаружены.
khim
Serge3leo
Хм. Не скажу за все процессоры, но конкретно у x86, L1D и далее физически адресуемые кэш. Иначе их протокол синхронизации кэш (инвалидации при записи на других ядрах/прцессорах/устройствах) работать не будет.
Вот кэш МОП, тот да, виртуализирован, но кэш инструкций в контексте Spectre рассматривать странно.
P.S. Впрочем, сделать L1D с виртуальными адресами, может оказаться неплохой идеей борьбы со Spectre (зачатком идеи).
Akon32
Достаточно выделять на процесс свой участок кэша, по сути так же, как выделяется память. Возможно, даже не физический участок кэша, а каким-то образом виртуализованный.
Железо потребуется заменить, но архитектура, система команд лишь немного расширится, а может и останется прежней.
khim
Разумеры кеша (особенно первого уровня) недостаточно вылики, чтобы всем десяткам (или даже сотням) процессов, работающих в современной OS выделять «по кусочку». Он за 20 с лишним лет эволюции там и остался на уровне 32K-64K. И тому есть фундаментальные причины.
Am0ralist
khim
Не обязательно даже иметь спец ядро для ОС. Просто при переключении в ядро — все спекуляции отключаются. Этом можно в том же ядре сделать.
a5b
Уязвима не архитектура (набор инструкций и регистров), а многие реализации — т.е. микроархитектура. В случае с RISC-V автор out-of-order ядра Boom рассказывал о теме:
https://content.riscv.org/wp-content/uploads/2018/05/13.00-13.15-Celio-Barcelona-Workshop-8-Talk.pdf
"Securing High-performance RISC-V Processors from Time Speculation" 2018-05
https://www.esperanto.ai/securing-high-performance-risc-v-processors-from-time-speculation-risc-v-barcelona-workshop/
Raspy
В наше время всё и не нужно переписывать. В первую очередь в этом будут заинтересованны военные и бизнес. Сделают РоС для серверного железа, в век микросервисов критические части системы переведут на новое железо. Наверняка напишут JVM и быстро напишут что-то nginx подобное (сколько там строк кода? Пара десятков тысяч?). Всякие молодые языки и так плодятся по 3 штуки в год, гугол быстро подсуетится. Лет через 10-15 всё серверное ПО будет работать на этой архитектуре, а там и до персоналок дойдёт.
DrPass
Проблемы архитектуры х86, они не в архитектуре х86, а в экономике. Эта самая х86 потому и победила более эффективные и удачные процессорные архитектуры за счет того, что тянула с собой legacy. Единственная альтернатива, которая теперь может с ней потягаться, ARM, стала настолько популярной за счёт того, что поселилась в нише встраиваемых и энергоэффективных устройств, на которую х86 практически не посягали, и вдруг эта ниша резко выросла с бумом гаджетов.
А фактор легаси работает до сих пор. Программы — они ведь более ценные, чем железяки.
Ну и второй немаловажный момент, на самом деле очень мало шансов, что новая хорошая архитектура окажется на самом деле хорошей, а не как обычно — с кучей недостатков и проблем, которые выявляются уже в процессе запуска, и на которые в старой архитектуре были костыли/заплатки.
powerman
Всё верно, но ведь ничего не делать со Spectre и оставить всё как есть тоже нельзя.
Nagg
Желание все выбросить и написать всё правильно выдает в комментаторе юношеский максимализм.
perfect_genius
Ну, все мы так начинали :)
snizovtsev
С другой стороны, сегодня большинство серверов состоят из полностью опенсорсного кода (за минусом фирмвари), а клиенты всё более сводятся к браузеру. Всё это скомпилировать из исходников в другую архитектуру — вполне решаемая задача. x86 сегодня выигрывает скорее именно в стандартизированной фирмвари, наличии виртуализации и хороших периферийных интерфейсах. Благодаря этому один дистрибутив ОС разных вендоров без изменений заводится на разных материнках, и автоматом подхватывает всё железо, чего ARM-у и не снилось.
khim
Вы вообще статью-то читали? Там же ключевой момент аж даже жирным выделены! Я процитирую:
Вы можете хоть уперекомпилироваться, но это ничего это не изменит, так как все процессоры делятся на два непересекающихся класса:1. Процессоры без спекулятивного исполнения, где 100500 уровней индирекции, порождённые архитектурными астронавтами, дико тормозят
2. Процессоры со спекулятивным исполнением, где избавиться от Spectre практически невозможно
Причём тут вообще x86? POWER и ARM точно так же подвержены Spectre, как и x86…
snizovtsev
Спасибо, но я в курсе про универсальность Spectre. А отвечал я на комментарий про x86 (а не статью), и лишь хотел сказать, что "легаси isa x86" сегодня не так страшно, как 10 лет назад.
khim
Как раз то Legacy, которое 10 лет назад было — не так страшно. На эмуляторе можно запустить, если приспичит.
А вот то, чего наворотили за последние 10 лет без быстрых процессоров со спекулятивным исполнением работать не будет…
Zet_Roy
Если такое и будут делать то ориентироваться будут на игровые консоли и серверы, рядовой пользователь вряд ли слезет с x86.
0xd34df00d
А для рядового пользователя эта уязвимость — не проблема.
DistortNeo
Похоронить — надо. Но проблема в самом спекулятивном выполнении, от которого отказаться попросту нельзя.
kikiwora
Хороший момент чтобы Apple перешла на свои процессоры на mac, как это уже сделала на iOS :)
khim
А ничего, что их процессор для iOS так же подвержен Spectre, как и все остальные?
kikiwora
С чего вдруг? Он базируется на RISC, а в статья явно сказано что они не подвержены этой проблеме.
timdorohin
VLIW не подвержены, RISC и CISC подвержены если используют внеочередное исполнение инструкций и предсказатель переходов.
kikiwora
Тогда вопрос к автору статьи а не ко мне. Было явно сказано что RISC не подверженып пробелмы спектра.
А вообще я думаю что Apple как производитель процессоров со своей архитектурой это быстро исправит. Потому всё остаётся как я и говорил.
Посмотрим. Только время покажет :)
khim
Там вообще много чего было сказано. В частности была ещё и ссылка на статью с говорящим названием: Патч против Spectre в iOS 11.2.2 замедляет устройства на 50%? (ответ, кстати, отрицательный: патч на 50% iOS не замедляет)… Так что…
Сама же идея что Apple может исправить фундаментальную проблему, потому что у них «своя архитектура», а Intel — не может, потому что… «ну тупыыыые» — тут неясно смеяться или плакать…
kikiwora
Нет, не потому.
Apple выпускает устройства полностью прорабатывая как железо так и софт.
И в случае изменения архитектуры проца просто подгонит софт и ничего при этом не сломается.
Intel же выпускает только процессоры, и в случае изменения архитектуры процессора возникнет вопрос с тем что внезапно перестанет работать какой-то софт, нужно будет куча исправлений.
Вспомните как Apple перешла с PPC на Intel. Они просто взяли и сказали — всё уже готово, забирайте. И у людей весь нужный софт работал и сразу был под рукой. А это полная смена архитектуры, пересборка всей ОС и модулей.
Я также уверен что Apple скоро переведёт маки на свой проц. Возможно на комбинацию в паре с Intel процом для совместимости со старой архитектурой или с каким-нибудь аппаратным эмулятором этой архитектуры, кто знает.
В iOS ещё есть другой момент — это закрытая ОС на которую невозможно поставить софт вредящий системе если пользователь сам сознательно себя не подвергает опастности. В случае с Windows это не так, увы.
Tyusha
Эх, Итаниум, Итаниум…
netch80
IA64, как и любой из известных VLIW, мог эффективно работать только при условии разумно предсказанных длительностей всех операций в группе. При разнице времени доступа L1::DRAM около 100 раз это нереально.
IA64 проектировался тогда же, когда Intel обжигалась об Rambus. Поэтому они и смогли вляпаться в такую авантюру.
Space__Elf
С какой скоростью будет работать эмуляция?
Помню как первые модели 64-битных процессоров от Intell провалились из-за тормозной эмуляции, и что 64-битные процессоры от AMD стали успешными благодаря аппаратной поддержке x86.
И разве на x86 была эта проблема?