Ксения (07.01.2018 13:54, просмотров: 199) ответил Скрипач на Китайские процессоры подвержены?-
- Ксения, ваши любимые "совершенные" процессоры ещё недостаточно "совершенны". Вот когда им добавят ещё сотню всяких кэшей и прочих ускорителей, тогда конечно. 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)