Однако ни один язык во все времена не мог претендовать на звание «идеального». Дело в том, что любой язык дает больше преимуществ носителю, чем человеку, который вынужден осваивать его «с нуля» во взрослом возрасте.
Это — не минус, а огромный плюс. Глуп тот народ, который откажется от этого.
Ну а миру давно требуется новое разделение языков.
Cкорее всего первое — предсказатель вероятности условных переходов, а второе — предсказатель точки назначения переходов по адресу из переменной. Но разницы по сути всё равно нет — всё это всего лишь разные аспекты забегания вперёд.
Ну тут однозначный вывод, что даже в спекулятивном выполнении права там всё-таки проверяются (иначе разницы бы не было). Но, судя по рассказам про meltdown — не всегда успевают.
У меня не получилось что либо прочитать из ядра ни на amd ни на intel проце. Из легально доступной памяти — с разной достоверностью (но везде достаточной для полного чтения) получается везде.
Вот тут twitter.com/brainsmoke/status/948561799875502080 кто-то показывает скриншот как он скомпилит эксплоит для meltdown и успешно применил его, можете у него спросить исходник (сам не пробовал, в твиттере не зареген и не уверен что он даст).
Неужели лицензионная политика Intel довела ситуацию до того, что ARM уже всерьёз рассматривают для серверов? Или тут в другом причины? Мне вот казалось, что всё что не x86 — это либо какие-то промышленные/энтерпрайзные мейнфреймы, либо контроллеры для всяких телефонов/планшетов и прочего embedded.
Если код, проверяющий наличие данных в кеше, выполнится спекулятивно (а он так скорее всего и выполнится даже если не прикладывать к этому специальных усилий, ну а если не выполнится — поставить перед ним что-то долгое и не нужное, чтобы задержать основной поток выполнения), а потом проц дойдёт до этой инструкции по-честному — он естественно не станет заново выбирать данные, так что затраты времени на выборку будут убраны во время спекулятивного исполнения.
Суть всех этих технологий в том что бы максимально ускорить выполнение операций. А ускорение всегда может быть измерено, как бы вы ни старались этого избежать. Нельзя убрать измеряемый эффект ускорения, не убрав само ускорение (то есть не обесценив то, ради чего изначально затевался и кеш и спекулятивные исполнения).
Во-первых, одно дело линукс из "свободного" софта, а другое дело — что-то проприетарное. Во втором случае гораздо выше вероятность вставки разной мощности палок в колёса тем кто ставит мимо официального репозитория.
Во-вторых, даже если вышеописанный пессимистичный сценарий не реализуется, то факт "windows store — основной способ распространения софта" уже сам по себе означает, что система так или иначе ориентирована на него, а остальное работает — ну просто работает, но без стремления со стороны авторов ОС делать что-то полезное для таких.
Виртуалка через meltdown не может прочитать ничего из других виртуалок на том же хосте, и не важно стоят ли какие-то патчи на любых ОС или не стоят. Это, естественно, не означает, что не может найтись какой-нить другой способ (особенно если гипервизор плохо сделан, но я не в курсе что там у них с качеством).
Повторю, в ваших фотографиях нет ничего, что позволяло бы их сопровождать язвительными комментариями, как вы это делаете. Безосновательные язвительные комментарии сложно объяснить как-то иначе, кроме как троллингом.
Эм, а что вы собственно пытаетесь этими фотографиями доказать/показать?
Skerrigan зря пошёл у вас на поводу, но его действия скорее всего носят эмоциональный характер — увидел наезд на свой город (фраза "на месте все еще хуже" и общий негативный тон поста, речь не про содержание) и решил его защищать.
На самом же деле в вашем сообщении ничего, кроме грубого тона (троллинга что ли?), и нет.
Вы не можете отключить спекулятивное выполнение от кэша, оно в этом случае просто потеряет смысл.
И? это как-то опровергает то что я написал выше? Да, нельзя отключить, а это значит что базовая суть уязвимости принципиально неисправима в данной архитектуре. Можно только затыкать её частные дыро-проявления.
Разве что сделать для него свой кэш, который будет синхронизироваться с основным.
Интересная идея, но не поможет. Во-первых, у меня есть подозрение что заметная часть кеша заполняется именно спекулятивными операциями (и без этого эффективность кеша резко упадёт), а, во-вторых, читать задержки можно тоже спекулятивно, хоть и чуть сложнее, таким образом получив доступ и к спекулятивному кешу.
Эта проблема (вместе с большей частью эпидемий) уйдёт, только когда Windows Store… станет основным способом дистрибьюции софта под Windows.
Тогда винда окончательно превратится из ОС общего назначения в очередную частную песочницу. Впрочем, как показывает опыт, "массовому потребителю" обычно это и надо. Хоть и печально.
Не верно. Общая причина есть — отпечатки в кеше от спекулятивного исполнения. kuraga333 всё верно пишет — суть тут одна и та же, просто разные методы эксплуатации. В том, что называется spectre, спекулятивное исполнение происходит в нереализуемой ветке if, а в том, что называется meltdown — в нереализуемой ветке «после исключения» (по сути тоже if, но не в коде программы, а в микрокоде/схеме проца, который проверяет права доступа). Первое обходит проверку уровня приложения, второе — проверку уровня архитектуры проца. Сам по себе «обход проверок» (и тренировка предсказателя ветвлений — тоже) — не уязвимость, а суть спекулятивного исполнения. Уязвимость в том что от этого исполнения остаются следы.
У меня для вас плохие новости: в вашем браузере (если это конечно не lynx или что-то подобное) этих дырок десятки, и будут они там не несколько недель, а годы. Хуже того, они будут и новые добавляться с новыми версиями.
По ссылке что-то слишком длинно расписано.
«Перехват» segfault делается через конструкцию __try __except (называется structured exception handler, SEH) в msvc и через sigaction(SIGSEGV) (посмотрите man sigaction) в unix-подобных системах. Из обработчика SIGSEGV, если не хотите завершать процесс, можно выпрыгнуть назад в основной код с помощью longjmp().
Важным моментом в атаке, кстати, является пункт «медленно и печально» — если array1_size лежит готовый где-то в кэше, процессор может не заморачиваться со спекулятивным вычислением, а просто быстро посчитать условие. Поэтому array1_size должен быть в ОЗУ, откуда его придётся долго доставать.
Только что проверял у себя на AMD. Видел инвалидацию кеша в примере из статьи — не понимал зачем она там нужна. Сам запускал не пример, а свою реализацию, там размер массива был вообще не в переменной а захардкожен. Аналог переменной x гарантировано был в кеше т.к. её только недавно записали. Всё работало.
На другом проце (тоже AMD) — не работало. Сейчас прочёл эту статью, дописал переменную с размером массива и её инвалидацию — заработало. Так что это не жёсткое требование, где-то работает, где-то нет.
Что особенно цинично, базовую возможность проведения атаки нам обеспечила проверка индекса массива, необходимая для обеспечения безопасности кода.
Нет, если бы там не было этой проверки, то её не пришлось бы взламывать, а программа бы неспекулятивно сделала тоже самое что тут получается только спекулятивно.
Это — не минус, а огромный плюс. Глуп тот народ, который откажется от этого.
Ну а миру давно требуется новое разделение языков.
Для меня вот это слово — не в русском, а кириллический транслит с английского. Я и не знал, что некоторые его уже "внесли" в язык.
Вот тут twitter.com/brainsmoke/status/948561799875502080 кто-то показывает скриншот как он скомпилит эксплоит для meltdown и успешно применил его, можете у него спросить исходник (сам не пробовал, в твиттере не зареген и не уверен что он даст).
Предлагаю хабру запретить анимированные картинки до ката.
Тоже хотел узнать — это только на винде так или не только?
Суть всех этих технологий в том что бы максимально ускорить выполнение операций. А ускорение всегда может быть измерено, как бы вы ни старались этого избежать. Нельзя убрать измеряемый эффект ускорения, не убрав само ускорение (то есть не обесценив то, ради чего изначально затевался и кеш и спекулятивные исполнения).
Во-первых, одно дело линукс из "свободного" софта, а другое дело — что-то проприетарное. Во втором случае гораздо выше вероятность вставки разной мощности палок в колёса тем кто ставит мимо официального репозитория.
Во-вторых, даже если вышеописанный пессимистичный сценарий не реализуется, то факт "windows store — основной способ распространения софта" уже сам по себе означает, что система так или иначе ориентирована на него, а остальное работает — ну просто работает, но без стремления со стороны авторов ОС делать что-то полезное для таких.
Повторю, в ваших фотографиях нет ничего, что позволяло бы их сопровождать язвительными комментариями, как вы это делаете. Безосновательные язвительные комментарии сложно объяснить как-то иначе, кроме как троллингом.
Эм, а что вы собственно пытаетесь этими фотографиями доказать/показать?
Skerrigan зря пошёл у вас на поводу, но его действия скорее всего носят эмоциональный характер — увидел наезд на свой город (фраза "на месте все еще хуже" и общий негативный тон поста, речь не про содержание) и решил его защищать.
На самом же деле в вашем сообщении ничего, кроме грубого тона (троллинга что ли?), и нет.
Не надо ложных аналогий.
И? это как-то опровергает то что я написал выше? Да, нельзя отключить, а это значит что базовая суть уязвимости принципиально неисправима в данной архитектуре. Можно только затыкать её частные дыро-проявления.
Интересная идея, но не поможет. Во-первых, у меня есть подозрение что заметная часть кеша заполняется именно спекулятивными операциями (и без этого эффективность кеша резко упадёт), а, во-вторых, читать задержки можно тоже спекулятивно, хоть и чуть сложнее, таким образом получив доступ и к спекулятивному кешу.
Тогда винда окончательно превратится из ОС общего назначения в очередную частную песочницу. Впрочем, как показывает опыт, "массовому потребителю" обычно это и надо. Хоть и печально.
«Перехват» segfault делается через конструкцию __try __except (называется structured exception handler, SEH) в msvc и через sigaction(SIGSEGV) (посмотрите man sigaction) в unix-подобных системах. Из обработчика SIGSEGV, если не хотите завершать процесс, можно выпрыгнуть назад в основной код с помощью longjmp().
Только что проверял у себя на AMD. Видел инвалидацию кеша в примере из статьи — не понимал зачем она там нужна. Сам запускал не пример, а свою реализацию, там размер массива был вообще не в переменной а захардкожен. Аналог переменной x гарантировано был в кеше т.к. её только недавно записали. Всё работало.
На другом проце (тоже AMD) — не работало. Сейчас прочёл эту статью, дописал переменную с размером массива и её инвалидацию — заработало. Так что это не жёсткое требование, где-то работает, где-то нет.
Нет, если бы там не было этой проверки, то её не пришлось бы взламывать, а программа бы неспекулятивно сделала тоже самое что тут получается только спекулятивно.