Toy example будет работать скорее всего везде, на любом процессоре. Но его еще надо запустить в ядре. eBPF — один способ, код для conditional branch с перекодированием — другой. Но их надо еще разместить в ядре, правильно воспользоваться и ухитриться очищать правильно кэш.
Насколько я понимаю, этот код всего лишь доказывает, что можно использовать определеные последовательности для запуска misprediction load при условном переходе и размещении данных в кэше. Для реальной эксплуатации все еще нужны определённые коды в ядре (victim_function при правильной оптимизации и запуске ), которой можно разбрасывать этот mispredicted load в зависимости от значения читаемого байта по разным кэш строчкам.
Да, это все еще опасно, гарантировать сложно. Некоторый код ядра делает именно эти операции (криптографический хэш, например).
Не перегнять, а переадресовывать. Иметь еще один кэш-маппинг, который назначает адрес в кэше и меняется при подтверждении загрузки. Ну и в этот момент и происходит вытеснение старой строки.
Не совсем. Чтобы починить текущие проблемы у Интела, надо — делать проверку доступа ДО того, как запускается подкачка кэш-а; разобраться с кривым TSX-NI, или отрубить его совсем — отрубали же на определенных процессорах из-за ошибок.
Ну а eBPF — это все-таки просто что-то типа троянского коня в ядре и больше софтверная проблема.
У AMD нету TSX-NI, и заставить через него срабатывать спекулятивную загрузку не получится. Не знаю правда что там с Advanced Synchronization Facility (ASF), может ли он быть тут использован.
Кроме того, такое впечатление, что AMD проверяет доступ до того, как запускает операцию загрузки в кэш.
> Примерно та же история с процессорами и Spectre.
Если права доступа к страницам ядра проверяются ДО запуска подгрузки в кэш, то остается только eBPF, который сам по себе бяка (JIT в ядре!). К тому же он кажется требует привелегий. Гуглы вроде не нашли в текущем коде ядра Linux подходящих последовательностей помимо возможности сформировать их через eBPF.
На Байкале-Т1 все эти баги не работают с гарантией если первые 128МБ памяти (там только 128МБ из первых 512МБ распределены под память) НЕ используются для user приложений. А к user страницам доступ либо через EVA, либо через HIGHMEM. В текущем ядре используется HIGHMEM, осталось только запретить рапсределять первые 128МБ под страницы user.
Такой запрет, кстати, ускорит работу с DMA, так как не нужен будет второй cache flush.
> Там даже был GIC, но в силу архитектуры Malta никуда не подключался :)
Ну к Интел-овскому контроллеру прерываний-то он подключен :)
Ну и Bus Err из CM обязан принимать.
> А что говорит Ральф? Хотя, кажется я знаю. Он хочет посмотреть их стабильность на реальном железе, а у него нет ни интераптива, ни p5600. Это, кстати, одна из причин, почему Байкальского кода нет до сих пор в маинстриме.
Можем поговорить об этом в оффисе. MIPS R6 нету не только у него, между прочим, а правки есть (хотя и кривые). А уж насчет правок работы с кэшем — я гарантирую, что SMP системы с CM у него _есть_, а правок не было… до тех пор, пока их не представил JamesH, и посему — неполные. И т.д и т.п. — типичный междусобойчик.
Я вообще-то гонял soak-тесты 3 недели на P5600 на Malta начиная с первых релизов, плюс массу других тестов раздельно и совместно. И сидел на шее у HW команды, доказывая им, что у них ошибка.
Но это было на 3.10.72 из моего репозитария на LMO. Если хотите убедиться, что проблема в SW а не в HW — погоняйте на этой версии, я специально ее еще держу и даже слегка поддерживаю, чтобы в критической ситуации можно было точно понять, кто виноват. Раз 5 уже пригодилось :)
> Кажется, никому не хочется смотреть на креш дамп при обмене с SATA
Единственное, что я тут могу сказать, что см мои правки. Я устал добиваться того, чтобы они прошли upstream.
> MAAR: Еще раз про стабильность. Проверяли?
Еще как! Но опять-таки — см мои правки, upstream до сих пор не содержит много насчет кэша. Долгое время они вообще конфигурили MAAR только на одном процессоре. А уж правки насчет агрессивного dataload/ifetch ядром Linux-а до сих пор непонятно в каком состоянии, см разницу в функции flush_icache_page() например.
> Просто формально патчи эти никак не повлияли на подъем Linux на Байкале.
Мы с Панчулом в «отладку» включаем обычно стабильность и эффективность, посему он так и написал. Напечатать Hello Word конечно очень большое дело, но это еще не конец. Собственно я только этим и занимался — проглядел код, который мне прислали, отметил проблемы и написал обратно в компанию. А потом компания еще ко мне пару раз обращалась насчет эффективности. А я им писал насчет пропущенных кусков насчет стабильности.
> Кстати, мы долго пользовались своими драйверами GIC/GCR/CPC до момента пока в маинстриме это все не стало более-менее стабильно на SMP (и все равно GIC время от времени ломают — как было, например в 4.6).
Увы, тут я только могу разделить с вами ваше негодование. После того, как весь этот код был исковеркан… увы. Как известо, 4.0 вообще не смог загрузиться на general MIPS, пришлось делать экстренные правки — представляете себе качество разработки! Майнстрим мне никак не подчиняется, критические патчи на стабильность сидят в LMO годами, пока кто-нибудь типа вас крик не поднимет.
И вообще — вы будете в головном офисе в RigaLand 10-го? Можем встретиться лично и поговорить подробно, тут мне не все удобно рассказывать.
Может не будем ссориться или меряться у кого больше?
Я же не собираюсь у вас отнимать авторство (я так понимаю, что вы один из разработчиков, да?). Но то, в первых версиях не был включен L2 prefetch в первом варианте ядра Linux, и для данных и для кода, UBoot гасил Config.MM и производительность падала, MAAR не были сконфигурены (30% при копировании), FTLB был выключен — это факт, а включили ли вы bonding — я до сих пор не в курсе.
Но я не ставлю вам это в вину, в конце концов это в наших интересах помочь вам все это запустить.
Что же касается патчей в ядро Linux, то я рекомендую вам обратить внимание на — https://git.linux-mips.org/cgit/yegoshin/mips.git/log/ — там все правки в ядро, которые я разработал в оригинальном варианте, включая EVA, MIPS R6, эмуляцию MIPS R2, все кэш flash правки (! рекомендую очень внимательно на них посмотреть, это важно!), GIC, защита стэка от выполнения команд, поддержка всех процессоров с 1004K до P5600 и многое другое. Увы, не все вошло upstream, а многое из того, что было сделано было переделано другими людьми под предлогом «несоответствия стандартам», хотя мне даже приходилось их пинать, чтобы хоть что-то сделали. Там только нет моей версии Power control — он не использует общий драйвер из-за его ошибочности и неэффективности, но мне прямо запретили этим заниматься в Linux ядре.
«Вы не захотите». Потребление энергии… смотрите на Android. И даже Nokia N900 с Meego вариантом Linux жрет энергии значительно больше, чем хочется.
Да и насчет security — полный швах в Linux-е. Его недаром на всех конференциях по security называют дипломатично Reach Execution Environment (REE) супротив TEE — Trusted Execution Environment.
Да, это все еще опасно, гарантировать сложно. Некоторый код ядра делает именно эти операции (криптографический хэш, например).
Ну а eBPF — это все-таки просто что-то типа троянского коня в ядре и больше софтверная проблема.
Кроме того, такое впечатление, что AMD проверяет доступ до того, как запускает операцию загрузки в кэш.
То есть, остаются только JIT exploit типа eBPF.
Если права доступа к страницам ядра проверяются ДО запуска подгрузки в кэш, то остается только eBPF, который сам по себе бяка (JIT в ядре!). К тому же он кажется требует привелегий. Гуглы вроде не нашли в текущем коде ядра Linux подходящих последовательностей помимо возможности сформировать их через eBPF.
Такой запрет, кстати, ускорит работу с DMA, так как не нужен будет второй cache flush.
Исходные тексты выложил на github:
https://github.com/lyegoshin/tinyVP
Ну к Интел-овскому контроллеру прерываний-то он подключен :)
Ну и Bus Err из CM обязан принимать.
> А что говорит Ральф? Хотя, кажется я знаю. Он хочет посмотреть их стабильность на реальном железе, а у него нет ни интераптива, ни p5600. Это, кстати, одна из причин, почему Байкальского кода нет до сих пор в маинстриме.
Можем поговорить об этом в оффисе. MIPS R6 нету не только у него, между прочим, а правки есть (хотя и кривые). А уж насчет правок работы с кэшем — я гарантирую, что SMP системы с CM у него _есть_, а правок не было… до тех пор, пока их не представил JamesH, и посему — неполные. И т.д и т.п. — типичный междусобойчик.
Я вообще-то гонял soak-тесты 3 недели на P5600 на Malta начиная с первых релизов, плюс массу других тестов раздельно и совместно. И сидел на шее у HW команды, доказывая им, что у них ошибка.
Но это было на 3.10.72 из моего репозитария на LMO. Если хотите убедиться, что проблема в SW а не в HW — погоняйте на этой версии, я специально ее еще держу и даже слегка поддерживаю, чтобы в критической ситуации можно было точно понять, кто виноват. Раз 5 уже пригодилось :)
> Кажется, никому не хочется смотреть на креш дамп при обмене с SATA
Единственное, что я тут могу сказать, что см мои правки. Я устал добиваться того, чтобы они прошли upstream.
> MAAR: Еще раз про стабильность. Проверяли?
Еще как! Но опять-таки — см мои правки, upstream до сих пор не содержит много насчет кэша. Долгое время они вообще конфигурили MAAR только на одном процессоре. А уж правки насчет агрессивного dataload/ifetch ядром Linux-а до сих пор непонятно в каком состоянии, см разницу в функции flush_icache_page() например.
> Просто формально патчи эти никак не повлияли на подъем Linux на Байкале.
Мы с Панчулом в «отладку» включаем обычно стабильность и эффективность, посему он так и написал. Напечатать Hello Word конечно очень большое дело, но это еще не конец. Собственно я только этим и занимался — проглядел код, который мне прислали, отметил проблемы и написал обратно в компанию. А потом компания еще ко мне пару раз обращалась насчет эффективности. А я им писал насчет пропущенных кусков насчет стабильности.
> Кстати, мы долго пользовались своими драйверами GIC/GCR/CPC до момента пока в маинстриме это все не стало более-менее стабильно на SMP (и все равно GIC время от времени ломают — как было, например в 4.6).
Увы, тут я только могу разделить с вами ваше негодование. После того, как весь этот код был исковеркан… увы. Как известо, 4.0 вообще не смог загрузиться на general MIPS, пришлось делать экстренные правки — представляете себе качество разработки! Майнстрим мне никак не подчиняется, критические патчи на стабильность сидят в LMO годами, пока кто-нибудь типа вас крик не поднимет.
И вообще — вы будете в головном офисе в RigaLand 10-го? Можем встретиться лично и поговорить подробно, тут мне не все удобно рассказывать.
Я же не собираюсь у вас отнимать авторство (я так понимаю, что вы один из разработчиков, да?). Но то, в первых версиях не был включен L2 prefetch в первом варианте ядра Linux, и для данных и для кода, UBoot гасил Config.MM и производительность падала, MAAR не были сконфигурены (30% при копировании), FTLB был выключен — это факт, а включили ли вы bonding — я до сих пор не в курсе.
Но я не ставлю вам это в вину, в конце концов это в наших интересах помочь вам все это запустить.
Что же касается патчей в ядро Linux, то я рекомендую вам обратить внимание на — https://git.linux-mips.org/cgit/yegoshin/mips.git/log/ — там все правки в ядро, которые я разработал в оригинальном варианте, включая EVA, MIPS R6, эмуляцию MIPS R2, все кэш flash правки (! рекомендую очень внимательно на них посмотреть, это важно!), GIC, защита стэка от выполнения команд, поддержка всех процессоров с 1004K до P5600 и многое другое. Увы, не все вошло upstream, а многое из того, что было сделано было переделано другими людьми под предлогом «несоответствия стандартам», хотя мне даже приходилось их пинать, чтобы хоть что-то сделали. Там только нет моей версии Power control — он не использует общий драйвер из-за его ошибочности и неэффективности, но мне прямо запретили этим заниматься в Linux ядре.
С 2015 я работаю над другими проектами.
Да и слабоваты они тогда в архитектуре MIPS-а были, хотя учились быстро.
Да и насчет security — полный швах в Linux-е. Его недаром на всех конференциях по security называют дипломатично Reach Execution Environment (REE) супротив TEE — Trusted Execution Environment.