Скрипач, пророк (07.01.2018 12:20 - 12:24, просмотров: 16082)... но не любой ценой.
-
- Это Путин виноват, адназначна. И русские хакеры, куда же без них... - SciFi(07.01.2018 22:23)
- Это виновата спешка, все быстрее, все больше, вот и выбрасывают на рынок сырой продукт. _nn(48 знак., 08.01.2018 09:45,
)
- Точна. На 20 лет поспешили. - SciFi(08.01.2018 10:38)
- Так все 20 лет и косячат, много нам открытий чудных готовит Интел еще - _nn(08.01.2018 14:33, )
- И не только, вот пишут про любимые Ксенией спекуляции и Xbox 360 CPU :) - mut(08.01.2018 22:37, ссылка, ссылка)
- Эти яйцеголовые совсем берега потеряли. Сами не понимают, что их детище вытворяет. Или понимают, но сидят под колпаком у Мюллера, но от этого не легче... - SciFi(08.01.2018 22:58)
- 1 Всем плевать на качество. 2 В случае хайпа очередной дыры можно скосить бабло за её ликвидацию. 3 Про потери от дыры давно все написано в лицензионном соглашении: вы не купили товар вы купили право им пользоваться: не хотите дыры - не Вова(622 знак., 08.01.2018 23:40)
- Эти яйцеголовые совсем берега потеряли. Сами не понимают, что их детище вытворяет. Или понимают, но сидят под колпаком у Мюллера, но от этого не легче... - SciFi(08.01.2018 22:58)
- И не только, вот пишут про любимые Ксенией спекуляции и Xbox 360 CPU :) - mut(08.01.2018 22:37, ссылка, ссылка)
- Так все 20 лет и косячат, много нам открытий чудных готовит Интел еще - _nn(08.01.2018 14:33,
- Точна. На 20 лет поспешили. - SciFi(08.01.2018 10:38)
- Это виновата спешка, все быстрее, все больше, вот и выбрасывают на рынок сырой продукт. _nn(48 знак., 08.01.2018 09:45,
- В операционных системах столько уязвимостей, что о процессорах просто и говорить не приходится. Проблемы, возникающие при нарушении защиты, должна решать операционная система, а не процессор. В том числе и вычищать кэш, если понадобится. И Ксения(109 знак., 07.01.2018 12:59)
- +100500. Говнокодеры ищут себе отмазу в уязвимостях процессора. Типа - "ничего личного..." - argus98(07.01.2018 22:09)
- Дык если бы это кодеры жаловались, а то жалуется всякая шваль :), которая в процессорах нифига не понимает, а лишь за свои пароли дрожит. - Ксения(07.01.2018 23:05)
- Шваль == говнокодеры + руководство говнокодерами. И всё встаёт на свои места - argus98(08.01.2018 00:17)
- Дык если бы это кодеры жаловались, а то жалуется всякая шваль :), которая в процессорах нифига не понимает, а лишь за свои пароли дрожит. - Ксения(07.01.2018 23:05)
- Я не об этом спросил. Скрипач(80 знак., 07.01.2018 13:03)
- А о другой части вопроса я уже раньше высказывалась => - Ксения(07.01.2018 13:26, ссылка)
- Там такая же конкуренция ,как у Макдака с Бургеркинг - _nn(07.01.2018 15:59, )
- ....под оглашение результатов года и выплату девидентов? Логично. - Скрипач(07.01.2018 13:39)
- Там такая же конкуренция ,как у Макдака с Бургеркинг - _nn(07.01.2018 15:59,
- А о другой части вопроса я уже раньше высказывалась => - Ксения(07.01.2018 13:26, ссылка)
- +100500. Говнокодеры ищут себе отмазу в уязвимостях процессора. Типа - "ничего личного..." - argus98(07.01.2018 22:09)
- Это "Байкальцы" организовали. Ща поднимутся на хайпе, купят долю в TSMC... - Точка опоры(07.01.2018 12:21)
- Когда-то же нужно начинать. Очевидно, что персональные компьютеры быдла будут замещены носимыми гаджетами. Компьютер не автомобиль, экологическим законодательством его не похоронишь. Приходится замедлять, делать дыры в безопасности, создавать Экспериментатор(369 знак., 07.01.2018 13:12, )
- Китайские процессоры подвержены? Скрипач(134 знак., 07.01.2018 13:22 - 13:24)
- "Спекулятивное выполнение команд" свойственно конвейеру лишь самых совершенных процессоров, т.к. относится к обеспечению запредельно высоких скоростей выполнения кода. Дерьмовые :) процессоры (включая пресловутый Байкал) до таких возможностей Ксения(21 знак., 07.01.2018 13:54)
- Ксения, ваши любимые "совершенные" процессоры ещё недостаточно "совершенны". Вот когда им добавят ещё сотню всяких кэшей и прочих ускорителей, тогда конечно. mut(96 знак., 07.01.2018 19:09 - 19:18)
- Надо уметь радоваться тому, что есть. Там паче, что совершенства в мире быть не может. А ошибок не совершает только тот, кто ничего не делает. - Ксения(07.01.2018 19:11)
- Теперь понятно для чего придуманы рождественские праздники - для таких "маленьких" радостей :) mut(62 знак., 07.01.2018 19:13 - 19:18)
- Надо уметь радоваться тому, что есть. Там паче, что совершенства в мире быть не может. А ошибок не совершает только тот, кто ничего не делает. - Ксения(07.01.2018 19:11)
- В данном случае это особенность процессоров с предельно высокой степенью параллелизма, когда ALU пытается предсказывать ситуацию наперед, загружая из памяти то, что может потребоваться для выполнения следующих команд кода, черед которых еще не Ксения(666 знак., 07.01.2018 14:26)
- При неправильном предсказании ошибок защиты не происходит именно потому что предсказание оказывается неверным и процессор сбрасывает спекулятивно выполненные команды. Но данные в кэше остаются. ОС не может с этим ничего сделать принципиально. - LightElf(07.01.2018 15:07)
- Может, поскольку у всех современных процов есть TLB. Исключи адресное пространство ядра из адресного пространства процесса и все будет в шоколаде, только системные вызовы протормозят. - ASDFS(07.01.2018 15:33)
- Ну да, в OS/2 такой херни нет. - LightElf(07.01.2018 15:44)
- ОС вполне может записать (столь же фиктивно) в ту же память нули или какую-то абракадабру, тем паче, что ей становиться известно, обращение к какому именно участку памяти вызвало защитное исключение. Т.е. сделать тоже самое, только не на чтение, а Ксения(110 знак., 07.01.2018 15:19)
- Ксения, попробуйте все же читать сначала. Не происходит никакого защитного исключения. ОС вообще ничего не знает о происходящем и потому ничего сделать не может. LightElf(295 знак., 07.01.2018 15:32)
- Но чтобы прочесть из кэша, уже хранящего в себе запрещенный участок памяти, по этому адресу нужно вторично обратиться. Иначе, как же из этого кэша секретную инфу получить? А при повторенном чтении кэш информацию выдаст, но исключение/прерывание Ксения(144 знак., 07.01.2018 15:40)
- Так самого чтения с точки зрения защитных механизмов не происходит - инструкция, благодаря спекулятивному выполнению которой, данные "читаются" (а на деле используются как индекс для загрузки кэш из другого, не запрещенного, участка памяти), a3r3(122 знак., 07.01.2018 15:51)
- Так я говорю уже о второй стадии, когда секретная информация уже оказалась в кэше. Как вы ее оттуда достанете, не вызывая прерывания защиты? - Ксения(07.01.2018 15:56)
- Косвенным образом a3r3(503 знак., 07.01.2018 16:07)
- В статье все описано. Запрещенная ячейка (1 байт) используется как индекс для доступа к одному из 256 элементов массива разрешенных ячеек. Далее по задержке можно выяснить, который именно элемент массива оказался в кэше, а значит - какое значение LightElf(29 знак., 07.01.2018 16:02)
- Очень просто - в спекулятивной ветке читается элемент своего массива по индексу, заданному искомым байтом. Оказавшийся в кэше элемент массива подскажет значение индекса. - ASDFS(07.01.2018 16:01)
- А с чего бы это ваш массив окажется по адресу спекулятивно прочитанной памяти? Если чтение было произведено из запрещенной для чтения памяти, то и в кэше этот байт будет принадлежать запрещенному адресу, а никак не вашему массиву. Т.е. в вашем Ксения(102 знак., 07.01.2018 16:10)
- Лучче ссыль на конкретный код приложу - LightElf(07.01.2018 17:26 - 19:24, ссылка)
- После того как мы взяли индекс массива нас запретный адрес больше не интересует и работаем мы исключительно с адресами нашего массива. В частности ищем какой элемент нашего массива был прочитан в рамках спекулятивного исполнения. - ASDFS(07.01.2018 16:14)
- Причем тут массивы и их индексы? Кэшируется только память! Т.е. память вашего массива прокэширована в одном месте, а спекулятивно добытые данные в другом. И эти кэши никак не могут перепутаться, чтобы вторые подлезли под первые. Адресацию вы Ксения(302 знак., 07.01.2018 16:24)
- Не нужно ничего читать. Измеряется скорость доступа к своим данным в кэш. Никаких формальных нарушений нет. - a3r3(07.01.2018 16:29)
- Ксюш, тебя клинит. Мы не пытаемся прочесть секретный байт, мы пытаемся узнать его значение. А для этого нам достаточно знать какой элемент массива был прочитан по индексу. - ASDFS(07.01.2018 16:28)
- Причем тут массивы и их индексы? Кэшируется только память! Т.е. память вашего массива прокэширована в одном месте, а спекулятивно добытые данные в другом. И эти кэши никак не могут перепутаться, чтобы вторые подлезли под первые. Адресацию вы Ксения(302 знак., 07.01.2018 16:24)
- А с чего бы это ваш массив окажется по адресу спекулятивно прочитанной памяти? Если чтение было произведено из запрещенной для чтения памяти, то и в кэше этот байт будет принадлежать запрещенному адресу, а никак не вашему массиву. Т.е. в вашем Ксения(102 знак., 07.01.2018 16:10)
- Так я говорю уже о второй стадии, когда секретная информация уже оказалась в кэше. Как вы ее оттуда достанете, не вызывая прерывания защиты? - Ксения(07.01.2018 15:56)
- Кэш не выдаст запрещенную информацию. Кэш косвенно (по задержке) выдаст, какой именно диапазон адресов в него загрузился. - LightElf(07.01.2018 15:47)
- Так самого чтения с точки зрения защитных механизмов не происходит - инструкция, благодаря спекулятивному выполнению которой, данные "читаются" (а на деле используются как индекс для загрузки кэш из другого, не запрещенного, участка памяти), a3r3(122 знак., 07.01.2018 15:51)
- Но чтобы прочесть из кэша, уже хранящего в себе запрещенный участок памяти, по этому адресу нужно вторично обратиться. Иначе, как же из этого кэша секретную инфу получить? А при повторенном чтении кэш информацию выдаст, но исключение/прерывание Ксения(144 знак., 07.01.2018 15:40)
- Ксения, попробуйте все же читать сначала. Не происходит никакого защитного исключения. ОС вообще ничего не знает о происходящем и потому ничего сделать не может. LightElf(295 знак., 07.01.2018 15:32)
- Может, поскольку у всех современных процов есть TLB. Исключи адресное пространство ядра из адресного пространства процесса и все будет в шоколаде, только системные вызовы протормозят. - ASDFS(07.01.2018 15:33)
- При неправильном предсказании ошибок защиты не происходит именно потому что предсказание оказывается неверным и процессор сбрасывает спекулятивно выполненные команды. Но данные в кэше остаются. ОС не может с этим ничего сделать принципиально. - LightElf(07.01.2018 15:07)
- Другими словами - "дуплища" свойственны "лишь самым совершенным процессорам"? ;-) - Точка опоры(07.01.2018 14:02)
- Ксения, ваши любимые "совершенные" процессоры ещё недостаточно "совершенны". Вот когда им добавят ещё сотню всяких кэшей и прочих ускорителей, тогда конечно. mut(96 знак., 07.01.2018 19:09 - 19:18)
- Меня больше Raspberry Pi 3b интересует. Давно планирую сделать на ней рабочую станцию для выхода в инет, пока времени нету. - Экспериментатор(07.01.2018 13:31, )
- слабо себе представляю, что там можно планировать? на uSD образ накатили, к монику jury093(158 знак., 07.01.2018 16:05, )
- Я так использовал полгода почти в 2017, вполне себе... единственное zram сразу ставить надо, памяти маловато =(( вот памяти бы в 2-4 гига и вообще отличная станция...процессора мощности хватает - sav6622(07.01.2018 14:32)
- Старшие модели АРМ, как я понял, тоже уязвимы. - Скрипач(07.01.2018 13:40)
- A53 - нет. - she(07.01.2018 13:41)
- слабо себе представляю, что там можно планировать? на uSD образ накатили, к монику jury093(158 знак., 07.01.2018 16:05,
- "Спекулятивное выполнение команд" свойственно конвейеру лишь самых совершенных процессоров, т.к. относится к обеспечению запредельно высоких скоростей выполнения кода. Дерьмовые :) процессоры (включая пресловутый Байкал) до таких возможностей Ксения(21 знак., 07.01.2018 13:54)
- Китайские процессоры подвержены? Скрипач(134 знак., 07.01.2018 13:22 - 13:24)
- Когда-то же нужно начинать. Очевидно, что персональные компьютеры быдла будут замещены носимыми гаджетами. Компьютер не автомобиль, экологическим законодательством его не похоронишь. Приходится замедлять, делать дыры в безопасности, создавать Экспериментатор(369 знак., 07.01.2018 13:12,
- Это Путин виноват, адназначна. И русские хакеры, куда же без них... - SciFi(07.01.2018 22:23)