На труде отличную оценку не давала получить повышенная кривизна рук (например, я не могу отпилить что-то достаточно ровно).
На физкультуре требовался некоторый уровень физического развития.
Вы хотите сказать, что нормальный, не ДЦП ребенок не сможет научиться пилить ровно или подтягиваться?
Могу судить по себе и своим одноклассникам — после внедрения этой системы (нам выпало учиться по ней последние 3 года) мотивация к реальной учебе (изучению) у всех выросла. И поскольку даже самые последние лентяи ходили переписывать по многу раз, пока честно не наработали на 3ку, даже они представление о предмете получили.
Да, скорее всего, этот метод не подойдет, чтобы атаковать любой произвольный процесс. Тут надо смотреть конкретно, что за кусок они использовали, можно только предположить, как именно регистры контроллируются. Допустим, это может быть удаленный вызов; обработка данных из сети.
Я бы не сказал, что это небольшой перерасход. К тому же, просто скопировать маппинг виртуальной памяти при загрузке процесса намного дешевле, чем читать и парсить библиотеку каждый раз. Эта часть — mapped file sections — есть в NT с первых версий, когда она еще не была Windows NT, на нее, кмк, много завязано.
Да и откуда нам знать, что этот другой процесс вообще исполнит избранный код?
Ну, например, запустить эту программу на своей домашней машинке и посмотреть, что там исполняется, а что нет. Учитывая, что они с ntdll игрались, шансов, что код исполнится — много.
Они же использовали Sleep, тут вообще почти что с гарантией.
Прочтите оригинал spectreattack.com/spectre.pdf, потому что можно долго Рабиновичем перепевать, все одно для деталей придется читать статью. Да и сам я мог неверно понять.
Кратко (если брать пример под NT из раздела 5.2) — берется код, который зашарен между процессами — dll, ntdll в случае примера. В своем, атакующего процесса, адресном пространстве кусок кода с ветвлением видоизменияется так, чтобы натренировать предсказатель переходов определенным образом. (в атакуемом процессе этот же кусок регулярно атакуемым процессом используется, т.к. это обычный библиотечный код). Предсказатель переходов сохраняет свои предсказания на уровне ЦП, а не процесса, поэтому в том, атакуемом процессе будет происходить то же. Плюс определенным образом сформированные входные параметры — в итоге происходит branch misprediction + чтение данных из пространства атакуемого процесса из-за спекулятивного выполнения, потому что мы натаскали бранч предиктор на заход «вовнутрь». Они потом будут сброшены, потому что переход не произойдет, но в кеше останутся. А из кеша эти данные извелкаются аналогично тому способу, что использован в Meltdown.
Вот только почему изоляция страниц спасает от Meltdown, а от Spectre — нет?
Получается, что через мелтдаун мы можем прочесть данные ядра, и оттуда, либо sensitive данные напрямую, либо уже косвенно — данные чужих процессов. Изоляция всех данных и кода ядра означает, что прочесть ничего не получится.
Spectre же заставляет чужой нам процесс спекулятивно читать данные из своего адресного пространства, которые мы потом подхватим через тайминг атаку на кеш. И этот второй чужой процесс тоже не сможет читать ядро, но зато мы сможем из его памяти вытащить данные так, будто мы в его адресном пространстве и находимся.
Spectre — отравление или обман предсказателя переходов. Чтение происходит из своего адресного пространства.
Тут немного чисто языковой путаницы. Да, чтение происходит из своего адресного пространства, только оно «свое» для чужого процесса, а не для атакующего.
Можно начать с «архитектуры компьютера» Танненбаума. Про предсказание переходов хорошо рассказано даже в старом учебнике «Организация ЭВМ и систем» Цилькера.
Вы хотите сказать, что нормальный, не ДЦП ребенок не сможет научиться пилить ровно или подтягиваться?
Ну, например, запустить эту программу на своей домашней машинке и посмотреть, что там исполняется, а что нет. Учитывая, что они с ntdll игрались, шансов, что код исполнится — много.
Они же использовали Sleep, тут вообще почти что с гарантией.
Кратко (если брать пример под NT из раздела 5.2) — берется код, который зашарен между процессами — dll, ntdll в случае примера. В своем, атакующего процесса, адресном пространстве кусок кода с ветвлением видоизменияется так, чтобы натренировать предсказатель переходов определенным образом. (в атакуемом процессе этот же кусок регулярно атакуемым процессом используется, т.к. это обычный библиотечный код). Предсказатель переходов сохраняет свои предсказания на уровне ЦП, а не процесса, поэтому в том, атакуемом процессе будет происходить то же. Плюс определенным образом сформированные входные параметры — в итоге происходит branch misprediction + чтение данных из пространства атакуемого процесса из-за спекулятивного выполнения, потому что мы натаскали бранч предиктор на заход «вовнутрь». Они потом будут сброшены, потому что переход не произойдет, но в кеше останутся. А из кеша эти данные извелкаются аналогично тому способу, что использован в Meltdown.
Получается, что через мелтдаун мы можем прочесть данные ядра, и оттуда, либо sensitive данные напрямую, либо уже косвенно — данные чужих процессов. Изоляция всех данных и кода ядра означает, что прочесть ничего не получится.
Spectre же заставляет чужой нам процесс спекулятивно читать данные из своего адресного пространства, которые мы потом подхватим через тайминг атаку на кеш. И этот второй чужой процесс тоже не сможет читать ядро, но зато мы сможем из его памяти вытащить данные так, будто мы в его адресном пространстве и находимся.
Тут немного чисто языковой путаницы. Да, чтение происходит из своего адресного пространства, только оно «свое» для чужого процесса, а не для атакующего.
Так… и ядро тоже в «своем» адресном пространстве, в этом суть проблемы же.
Зачем?