Здравствуйте, LaptevVV, Вы писали:
LVV>что проблема с вирусами — непосредственно в аппаратуре. LVV>Де предсказание переходов — это корень зла...
Не в аппаратуре и не в ее архитектуре, а всего-то в реализации отдельных тонких моментов. Поставить туда аппаратные проверки (возможно, отключаемые), и никаких проблем.
Выполнение любого стороннего (third party) кода несет в себе риски. Запуская софт в вакууме под администратором уже само по себе несет в себе бОльшую потенциальную опасность, чем какие-то потенциальные почти не наблюдаемые эффекты второго или даже третьего порядка.
Ну да, частичные воспроизведения spectre/meltdown были, но честно говоря не вижу вообще ни единого резона было применять те софтовые залипухи везде, где можно.
Залепив эту уязвимость — мы забыли, что первопричина — это исполнение этого самого зловредного кода.
ADD: Что, если зловредный код банально бахнет файлы из локального профиля пользователя? Прав на это более чем достаточно. Понравится мало кому.
Здравствуйте, Mystic Artifact, Вы писали:
MA>Залепив эту уязвимость — мы забыли, что первопричина — это исполнение этого самого зловредного кода.
Неверно. Эти уязвимости актуальны для систем, где ты не контролируешь код, выполняемый на одном железе с твоим, для всяких облаков и VPS хостингов. Тебе и не требуется чего-то запускать, злоумышленник это сделает сам.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
LVV>Тут вот пишут: https://habr.com/ru/post/441378/ LVV>что проблема с вирусами — непосредственно в аппаратуре. LVV>Де предсказание переходов — это корень зла...
Кому-то поперёк одного места рост возможностей вычислительной техники в руках _электората_. Нужно срочное "объективное" оправдание "для вашей же безопасности", по которому следующие процессоры делать медленнее и медленнее предыдущих.
Здравствуйте, Mystic Artifact, Вы писали:
MA> Выполнение любого стороннего (third party) кода несет в себе риски. Запуская софт в вакууме под администратором уже само по себе несет в себе бОльшую потенциальную опасность, чем какие-то потенциальные почти не наблюдаемые эффекты второго или даже третьего порядка.
В браузере javascript уже отключил? https://react-etc.net/page/javascript-spectre-meltdown-faq
Скрипты запущенные в песочнице (процессе рендерере) не получат ничего интересного даже из своего адресного пространства, а со всей этой асинхронией и/или легкостью ограничения точности таймеров — о ядре и мечтать не надо.
Если же рассматривать наличие зловредного кода на машине, и, допустим, вражеские скрипты внедряются во все подряд — то вроде как более традиционный граб потенциально полезных данных будет более эффективен. Но это опять про установку левого софта.
Здравствуйте, LaptevVV, Вы писали:
LVV>Де предсказание переходов — это корень зла...
Корень зла — нахождение данных ОС в адресном пространстве процесса.
Здравствуйте, Mystic Artifact, Вы писали:
MA>·>В браузере javascript уже отключил? MA>·>https://react-etc.net/page/javascript-spectre-meltdown-faq MA> Зачем? MA>Скрипты запущенные в песочнице (процессе рендерере) не получат ничего интересного даже из своего адресного пространства,
Браузеры не запускают каждую закладку в отдельном процессе. Открытых закладок может быть сотни, но браузер запускает только штук 5 песочниц. А значит какой-нибудь вирус в закладке условного вконтакта может читать данные из закладки какого-нибудь условного сбербанка. Не говоря уж о памяти самого браузера, где могут лежать вкусные пароли, клиентские серты, сессионные ключи, потом ещё и память операционки.
MA>а со всей этой асинхронией и/или легкостью ограничения точности таймеров — о ядре и мечтать не надо.
Не понял причём тут таймеры. Тайминги вычисляются на основе многократного выполнения, просто прокручивается в цикле много-много раз и собирается статистика, поэтому спорадические события от асинхронщины, прерываний, етс — на статистическое распределение в целом не влияют.
MA> Если же рассматривать наличие зловредного кода на машине, и, допустим, вражеские скрипты внедряются во все подряд — то вроде как более традиционный граб потенциально полезных данных будет более эффективен. Но это опять про установку левого софта.
Как я понял, единственное что спасло "апокалипсиса" — специфичность каждого окружения, поэтому массовый вирус, делающий что-то интересное практически невозможен. Но если кому-то захочется взломать конкретно тебя — то дело плохо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Браузеры не запускают каждую закладку в отдельном процессе. Открытых закладок может быть сотни, но браузер запускает только штук 5 песочниц. А значит какой-нибудь вирус в закладке условного вконтакта может читать данные из закладки какого-нибудь условного сбербанка. Не говоря уж о памяти самого браузера, где могут лежать вкусные пароли, клиентские серты, сессионные ключи, потом ещё и память операционки.
Эти лимиты зависят от наличия памяти и/или жестко настраиваются. Ничего не мешает позволить создать 200 процессов по одному, на каждую вкладку. Сейчас все идет к тому, что даже cross-origin фреймы будут хостится в разных процессах (если не уже.)
"Не говоря уж о памяти самого браузера" — память самого браузера находится в ином процессе, вместе со всем сетевым слоем. К слову сказать, в хроме — сетевой сервис скоро уедет в отдельный процесс.
Хотя, это все конечно, зависит от конкретного браузера, но по большому счету их уже сейчас три с вариациями.
MA>>а со всей этой асинхронией и/или легкостью ограничения точности таймеров — о ядре и мечтать не надо. ·>Не понял причём тут таймеры. Тайминги вычисляются на основе многократного выполнения, просто прокручивается в цикле много-много раз и собирается статистика, поэтому спорадические события от асинхронщины, прерываний, етс — на статистическое распределение в целом не влияют.
Таймеры при том, что их точность, напрямую влияет на время сбора статистики. А асинхронщина при том, что — неизвестно сколько еще микрозадач может быть выполнено до получения колбэка вводя шум в данные. При чем, чем больше нагруженности тем больше шума. Табы объединены в один процесс? Еще больше шума. Собственно про таймеры, это ж одно из предлагаемых путей решения. Но, если в обычном мире приложений... это не выглядит рабочим, то в вебе — вполне. (Хотя я сам отношусь скептически.)
SPOILER: Speculative Load Hazards Boost Rowhammer and Cache Attacks
Abstract
Modern microarchitectures incorporate optimization techniques
such as speculative loads and store forwarding to
improve the memory bottleneck. The processor executes the
load speculatively before the stores, and forwards the data
of a preceding store to the load if there is a potential dependency.
This enhances performance since the load does not
have to wait for preceding stores to complete. However, the
dependency prediction relies on partial address information,
which may lead to false dependencies and stall hazards.
In this work, we are the first to show that the dependency
resolution logic that serves the speculative load can be exploited
to gain information about the physical page mappings.
Microarchitectural side-channel attacks such as Rowhammer
and cache attacks rely on the reverse engineering of the virtualto-
physical address mapping. We propose the SPOILER attack
which exploits this leakage to speed up this reverse engineering
by a factor of 256. Then, we show how this can improve
the Prime+Probe attack by a 4096 factor speed up of the
eviction set search, even from sandboxed environments like
JavaScript. Finally, we improve the Rowhammer attack by
showing how SPOILER helps to conduct DRAM row conflicts
deterministically with up to 100% chance, and by demonstrating
a double-sided Rowhammer attack with normal user’s
privilege. The later is due to the possibility of detecting contiguous
memory pages using the SPOILER leakage.
Но, если в обычном мире приложений... это не выглядит рабочим, то в вебе — вполне. (Хотя я сам отношусь скептически.)
