[snvoronkov]

14 минут назад, ttttt сказал:

Это компилятор должен пихать или статический анализатор, о борьбе ручками со Spectre конечно можно забыть.

Это тоже разновидность "ручками" будет. Никто не мешает на асме вставки делать,ведь правда?

 

Только хардкор, типа мипсовского EVA - настоящее лечение. Все остальное - сплошное показательство и очковтирательство.

[ttttt]

Архитектура от компилятора неотделима, если в компиляторе это "ручками", то и в архитектуре тоже "ручками". У VLIW архитектур, например, спекулятивное исполнение генерируется компилятором.

А вот мипсовая EVA тут причем - не знаю.

[snvoronkov]

4 минуты назад, ttttt сказал:

А вот мипсовая EVA тут причем - не знаю.

Офигительный способ разделения адресных пространств виртуалок или даже процессов. Интеловский ldt на каждый процесс по сравнению с ним как каменный топор против револьвера.

 

Хотя, от выхода за границы массива не спасёт, коли через него контролировать собрались. :-)

[Tosha]

В суперскалярных процессорах когда десятки команд исполняются параллельно никакая программная защита не спасет, потому как эта защита работает только при последовательном исполнении. Тут сам процессор должен обеспечивать защиту. Самое лучшее - при отвергании результата предварительно исполненной/подготовленной команды надо также очищать кэш. Желательно не весь :)

Защиту процессов друг от друга и ядра делают через другие механизмы безопасности (раз права на страницы не работают то через видимость страниц или определения прав на основе pcid). Но вот процесс исполняющий произвольный код  лучше считать небезопасным. Потому что нет аппаратных защит памяти процесса от себя самого.

[ttttt]

Говорили, говорили и опять за свое. Я же тебе выше показал пример 100% работающей программной защиты. Второе, лучшая защита может быть только программная, когда харда делающего неизвестно что спекулятивно вообще нет. Третье, очищать кэш после спекулятивного исполнения никто никогда не будет, кэши критичны для производительности. Четвертое, защиту процессов друга от друга ядра не обеспечивают в контексте Spectre, ядро только себя защищает от Spectre из юзерспейса и от Meltdown. Раз это до сих пор не понятно, то я сдаюсь.

[Ivan_83]

3 часа назад, snvoronkov сказал:

Офигительный способ разделения адресных пространств виртуалок или даже процессов.

У амд есть тоже какая то штука, которая делает именно отдельные адресные пространства именно  для виртуалок, забыл название, но есть уже лет 10 как.

И ещё теперь амд вроде как на лету шифрует память, и кажется там сделали так что виртуалки могут шифровать свою память ключами о которых хост не в курсе, видимо PSP как то учавствует.

[Tosha]

3 часа назад, ttttt сказал:

Второе, лучшая защита может быть только программная, когда харда делающего неизвестно что спекулятивно вообще нет. Третье, очищать кэш после спекулятивного исполнения никто никогда не будет, кэши критичны для производительности.

Если программная защита панацея то зачем тогда вообще эти аппаратные изыски защит памяти?  Что касается кэша то выходов то всего два 1) не читать в кэш то что предположительно сломает защиту 2) вычищать из кэша то что может предположительно сломать защиту. Я тут навскидку и не скажу что проще сделать. Думаю что первое проще но могу ошибиться. В параметрах операции же есть адрес. При отмене ее можно давать команду сброса кэша для этого адреса. Да и для быстродействия вторая схема выгоднее может быть. AMD насколько я понимаю реализовал первый вариант. Интел же слишком сильно недосмотрел. Казалось бы - ну что такого что кэш почитает немного больше данных. А вот боком вышло. Оказалось можно узнать содержимое ячейки памяти косвенно.

[ttttt]

Да все одинаково "недосмотрели", AMD такое же дерьмо и только из чистой случайности их процессоры не подвержены Meltdown. Вы же не думаете что у них там никто не в курсе о side channel атаках? Конечно в курсе и могли во время верификации все проблемы найти. Но зачем, Intel-AMD - это же олигополия, держат рынок пк очень крепко, и давно забили и на безопасность, и на архитектуры процессоров и просто высасывают деньги с рынка. Кто ж им что сделает. Могут десятилетиями не замечать изменившиеся потребности к безопасности. Дожились до того, что даже у госушного Эльбруса под распил лучше архитектура получилась. И уже чуть ли ни каждый студент компьютерных наук знает, как сделать лучше процессор, чем у Интела, с той самой программной спекуляцией, а не хардверной. Короче мир так устроен, что монополизация приводит к деградации.

[Ivan_83]

6 минут назад, ttttt сказал:

Но зачем, Intel-AMD - это же олигополия, держат рынок пк очень крепко, и давно забили и на безопасность, и на архитектуры процессоров и просто высасывают деньги с рынка.

Ты как то отстал от жизни.

Я даже не буду начинать что VIA возвращается на х86 рынок и может ещё кто то х86 делал по мелочи и тормознутое, про эльбрус с его эмуляцией х86.

Я просто напомню тебе что есть ARM, и теперь там работает венда и в этой венде работают проги собранные для х86.

Это означает что как минимум атомы теперь почти никому не нужны будут, уж как минимум в ноутах и планшетах. А там по мере развития и средний и может до хай перформанс сегмента доберутся.

Да и без венды всякие хромбуки с андройдами маленько эту нишу отгрызали.

 

Насчёт забили на архитектуры - тут ты не прав, если только у тебя нет инсайда.

Сейчас х86 это огромная махина, в которой всё ещё поддерживается совместимость чуть ли не до 16 битных предков, в которой сверху наворочена куча всего. В таких условиях и развивать трудно и придумать новое с нуля чтобы было не хуже тоже трудно и долго, даже если заимствовать отдельные IP куски, как интел делало с видюхами а амд с контроллером памяти и кажется сата, а может там и юзби и пр.

Я слышал что интел пыталось родить нечто лучше коре но не шмогла.

Сейчас амд их наконец то догнало и у них ещё немного запасу есть куда вырасти: контроллер памяти на 4 канала, плавучку расширить и avx подтянуть до реальных 256 бит, хотя они говорили что им это не надо, типа сил дохрена на это уйдёт а приросту чуть. А AES-NI у амд уже ощутимо шустрее.

 

Лично у меня есть ощущение что райзен может стать моей последней х86 платформой, а дальше арм, эльбрус или нечто квантовое.

У меня платформы живут: 2-6-9 лет, те всё дольше, прогресс замедляется, нет смысла менять мать+проц, я только диски постоянно покупаю, видюхи периодически бюджетные, да клавы с мышами :)

[snvoronkov]

9 часов назад, ttttt сказал:

Третье, очищать кэш после спекулятивного исполнения никто никогда не будет, кэши критичны для производительности.

Есть ТЕПОЕ решение имели RISC-V в контексте именно "привидения" - спекулятивно префетч данных из памяти не происходит вообще НИКОГДА. И никаких извращений городить не надо. :-)

 

3 часа назад, Ivan_83 сказал:

да клавы с мышами

Плохие клавы, значит. Моей на работе уже 17 лет. :-)))

[Aliech]

7 часов назад, Ivan_83 сказал:

Ты как то отстал от жизни.

Я даже не буду начинать что VIA возвращается на х86 рынок и может ещё кто то х86 делал по мелочи и тормознутое, про эльбрус с его эмуляцией х86.

Я просто напомню тебе что есть ARM, и теперь там работает венда и в этой венде работают проги собранные для х86.

Это означает что как минимум атомы теперь почти никому не нужны будут, уж как минимум в ноутах и планшетах. А там по мере развития и средний и может до хай перформанс сегмента доберутся.

Да и без венды всякие хромбуки с андройдами маленько эту нишу отгрызали.

 

Насчёт забили на архитектуры - тут ты не прав, если только у тебя нет инсайда.

Сейчас х86 это огромная махина, в которой всё ещё поддерживается совместимость чуть ли не до 16 битных предков, в которой сверху наворочена куча всего. В таких условиях и развивать трудно и придумать новое с нуля чтобы было не хуже тоже трудно и долго, даже если заимствовать отдельные IP куски, как интел делало с видюхами а амд с контроллером памяти и кажется сата, а может там и юзби и пр.

Я слышал что интел пыталось родить нечто лучше коре но не шмогла.

Сейчас амд их наконец то догнало и у них ещё немного запасу есть куда вырасти: контроллер памяти на 4 канала, плавучку расширить и avx подтянуть до реальных 256 бит, хотя они говорили что им это не надо, типа сил дохрена на это уйдёт а приросту чуть. А AES-NI у амд уже ощутимо шустрее.

 

Лично у меня есть ощущение что райзен может стать моей последней х86 платформой, а дальше арм, эльбрус или нечто квантовое.

У меня платформы живут: 2-6-9 лет, те всё дольше, прогресс замедляется, нет смысла менять мать+проц, я только диски постоянно покупаю, видюхи периодически бюджетные, да клавы с мышами :)

 

Какой суровый пост...

Ну, по-первых, в Эльбрусе не эмуляция а трансляция. Как в сгинувших Трансметах. К сожалению у меня нет знакомых, которые её использовали, так как... профильные исполнители умеют не в x86 софт.

Во-вторых, ARM таки не огонь. Он начинает приближаться к понятию "огонь" только когда есть возможность оптимизировать всё ПО под конкретный проц и/или семейство. Вы собрались на ARM и хотите максимальной отдачи? Чтож, время собирать свой дистрибутив, да может даже на несколько веток, если ARM'ы разные будут ;)

В-третьих, Atom'у сильно не так страшно, если ему компилятор SSE2 соберёт. Он это будет исполнять достаточно эффективно и не критично отстанет от себя же, если его SSE4 грузили бы. А вот если в ARM с VFPv4 грузят VFPv1 или soft-fp, то, считай, деньги на ветер. Так что когда нет возможности обеспечить целиком экосистему для железки, x86 вне конкуренции.

В-четвёртых, таки ARM может в хай-энд и конвергентные вычисления. Для этого есть Cavium ThunderX. НО! Оно тоже сильно не эффективно в ситуации, когда нет оптимизированных задач. Ну и ещё оно ИЗНАЧАЛЬНО утыкано анальными зондами типа UEFI. AMI в друзьях, - плохой знак.

 

AMD же... уже не торт. Конечно они делают хорошие попытки. Только вот сейчас это ещё больший чёрный ящик, чем intel. И хакать его никто не торопится. Так что в рамках coreboot'а для меня продукция intel'а выглядит как понятные железки. А благодаря комитам google, - ещё и удобные в обращении жлезки. AMD на фоне них вообще не торт. Хотя и очень большой поклонник ребят из Санивейла, но приходится констатировать, что годнота закончилась на Fam10 (у Intel'а раньше годноты не стало, но большие конторы тратят время своих сотрудников, чтобы документировать их поле с граблями).

 

Это были вести с полей)

[stalker86]

23 часа назад, jffulcrum сказал:

Не совсем свежими - это 10 лет, Launch Date Q4'07

Да...но при этом на прошлом ядре полёт нормальный. а тут вот таких вот сообщений тонна и еле-еле шевелящийся тазик. Сижу пытаюсь понять что происходит и куда ползти
 

 

21 час назад, snvoronkov сказал:

23 часа назад, stalker86 сказал:

Похоже сломали работу с некоторыми не совсем свежими камнями ( E5430 ).

Видимо, что-то необычное в настройках?

 

да вот именно что нет ничего особенного там, обычный сервер с апачиком и нгинксом. В биосе тоже ничего  такого.
Пока понять не могу откуда ошибки, откат на прошлое ядро и ошибка исчезает

[snvoronkov]

41 минуту назад, stalker86 сказал:

да вот именно что нет ничего особенного там, обычный сервер с апачиком и нгинксом. В биосе тоже ничего  такого.
Пока понять не могу откуда ошибки, откат на прошлое ядро и ошибка исчезает

У меня есть с ровно таким процессором сервер, но на нем CentOS 6 стоит.  Там ядро вообще бородатое. :-) И вот на нем никаких багов не найдено.

[Ivan_83]

6 часов назад, snvoronkov сказал:

Плохие клавы, значит. Моей на работе уже 17 лет. :-)))

Они боятся воды, там дорожки растворяются в прямом смысле.

 

 

1 час назад, Aliech сказал:

ARM таки не огонь. Он начинает приближаться к понятию "огонь" только когда есть возможность оптимизировать всё ПО под конкретный проц и/или семейство. Вы собрались на ARM и хотите максимальной отдачи? Чтож, время собирать свой дистрибутив, да может даже на несколько веток, если ARM'ы разные будут ;)

Это совсем не проблема, у меня же фря везде.

 

1 час назад, Aliech сказал:

Atom'у сильно не так страшно, если ему компилятор SSE2 соберёт. Он это будет исполнять достаточно эффективно и не критично отстанет от себя же, если его SSE4 грузили бы. А вот если в ARM с VFPv4 грузят VFPv1 или soft-fp, то, считай, деньги на ветер. Так что когда нет возможности обеспечить целиком экосистему для железки, x86 вне конкуренции.

fp не так уж и часто используется, если что.

Насчёт прочих векторных инструкций, на х86 оно тоже не сильно активно юзается компелятором при сборке ОС и софта, только если софт явно сам не захочет.

К тому же, х86 тоже далеко не однороден в плане производительности, как минимум SSE/AVX даже на интелах бывает что весьма неожиданно или ускоряется или обваливается производительность, а уж если тут ещё и амд добавить, то вообще жуткая сказка начинается при попытке написать код который работает быстро везде :)

 

1 час назад, Aliech сказал:

таки ARM может в хай-энд и конвергентные вычисления. Для этого есть Cavium ThunderX. НО! Оно тоже сильно не эффективно в ситуации, когда нет оптимизированных задач. Ну и ещё оно ИЗНАЧАЛЬНО утыкано анальными зондами типа UEFI. AMI в друзьях, - плохой знак.

Если есть доки то EFI не проблема.

Он и так сам по себе не проблема.

 

1 час назад, Aliech сказал:

Так что в рамках coreboot'а для меня продукция intel'а выглядит как понятные железки.

Коребут у интела, насколько помню, кончается примерно на на первых корах/процах до 2009 года, когда МЕ ещё была опционально.

Но если тебя это так парит то нужно брать только наши процы, у наших ИМХО просто сил/средств нет на встраивание бэкдоров :)

[stalker86]

1 час назад, snvoronkov сказал:

У меня есть с ровно таким процессором сервер, но на нем CentOS 6 стоит.  Там ядро вообще бородатое. :-) И вот на нем никаких багов не найдено.

так о том и речь что что-то взорвалось на новом ядре.

 

Ещё 1 интересная вещь... согласно

https://security-tracker.debian.org/tracker/CVE-2017-5754
 

этот фикс есть и в стейбле и в олд стейбле. а по факту запись о нём вижу только вот в этом взорвавшемся ядре

 

linux (3.2.96-3) wheezy-security; urgency=high

  * [amd64] Implement Kernel Page Table Isolation (KPTI, aka KAISER)
    (CVE-2017-5754)

 

а вот в олдстейбле  не вижу

В стейбле кучка  записей про kaiser и ни слова про CVE-2017-5754

[stalker86]

хех... что-то всё таки нашли
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887106

[Aliech]

2 часа назад, Ivan_83 сказал:

Они боятся воды, там дорожки растворяются в прямом смысле.

 

 

Это совсем не проблема, у меня же фря везде.

 

fp не так уж и часто используется, если что.

Насчёт прочих векторных инструкций, на х86 оно тоже не сильно активно юзается компелятором при сборке ОС и софта, только если софт явно сам не захочет.

К тому же, х86 тоже далеко не однороден в плане производительности, как минимум SSE/AVX даже на интелах бывает что весьма неожиданно или ускоряется или обваливается производительность, а уж если тут ещё и амд добавить, то вообще жуткая сказка начинается при попытке написать код который работает быстро везде :)

 

Если есть доки то EFI не проблема.

Он и так сам по себе не проблема.

 

Коребут у интела, насколько помню, кончается примерно на на первых корах/процах до 2009 года, когда МЕ ещё была опционально.

Но если тебя это так парит то нужно брать только наши процы, у наших ИМХО просто сил/средств нет на встраивание бэкдоров :)

 

Так яж и написал, что прибавка в скорости от более продвинутых векторных инструкций на x86 не так проявляется, как на ARM'е. На любом x86ом микрокод (который, собственно, и предоставляет все сложные инструкции) разложит это так, чтобы процессор эффективней был загружен. Ну ARM хорош своей простотой. И он не должен думать за вас, как лучше исполнить тот код, который на него загнали. Компилятор не подготовил код под набор SIMD, доступных на CPU? CPU будет работать не эффективно.

 

UEFI со встроенным IPMI, - у меня такое заказчик в жизни бы не купил. Но это специфика такая. И второй уровень защиты от НДВ по МО РФ.

 

Ну и coreboot на intel'е закачивается на Haswell'е (парни из НИЦЭВТа сейчас парются, они даже с нуля мать развели). У меня же, например, ME в серийной продукции порезан. На Ivy Bridge под Socket G2.

[Черномазов]

В 15.01.2018 в 04:00, Ivan_83 сказал:

Я слышал что интел пыталось родить нечто лучше коре но не шмогла.

У Интелов были Itanium'ы, у которых не было обратной совместимости с x86. Тут-то их AMD (на некоторое время) со своим x86-64 и дёрнули...

 

При прочих равных (то, что это защита чужих процессов от своего, а не наоборот), мне не совсем понятно, как игры с масками на индексы спасут от выхода за пределы массива, если его размерность не кратна степеням двойки? Согласитесь, условие достаточно жёсткое, особенно, на больших числах.

 

[Ivan_83]

5 часов назад, Черномазов сказал:

У Интелов были Itanium'ы, у которых не было обратной совместимости с x86. Тут-то их AMD (на некоторое время) со своим x86-64 и дёрнули...

Так итаниумы просто были дорогими и только для корпоратов доступны, поэтому там софта было нисколько (под венду) и они в целом так и остались никому не нужными, ибо не понятно зачем весь секс за такие деньги.

[Tosha]

9 часов назад, Черномазов сказал:

мне не совсем понятно, как игры с масками на индексы спасут от выхода за пределы массива

никак - сам пробный массив полностью доступен, а чтение с уязвимого адреса (данные чтения с которого задают индекс в пробном массиве) происходит побитово (побайтово ведет к более частым ошибкам и все равно не сильно быстрее). 

И любые проверки на основе условных переходов не сработают.

А вот маска могла бы...

В принципе, теоретически, если операционная система специально разделит память процесса на зоны с выравниванием по степеням двойки то может быть идея с наложением маски может помочь. Но эту поддержку надо еще ухитрится реализовать. Как в самой системе так и в компиляторах. Например, вторую четверть адресного пространства доступного процессу (третья и четвертая четверть - память ядра) зарезервировать для песочницы и в коде песочницы в любом адресе устанавливать предпоследний бит адреса не давая зайти в нижнюю область. 

Но это же сколько надо переделывать! Специальное выделение памяти в операционной системе... Опции компилятора в заданной зоне кода обрамлять адрес чтения из памяти маской (and 0b0111111... or 0b0100000...)

Но тогда все равно останется уязвимость - память песочницы можно будет читать. Т.е. в рамках одной песочницы нельзя защитить данные разных скриптов.

[Ivan_83]

3 минуты назад, Tosha сказал:

В принципе, теоретически, если операционная система специально разделит память процесса на зоны с выравниванием по степеням двойки то может быть идея с наложением маски может помочь.

Она и так выделяется страницами по 4кб, есть ещё страницы по 1гб, но используются редко. Это именно аппаратное, под х86.

Дальше в дело вступает аллокатор памяти, и он вообще у приложения может быть свой собственный, а у системы он будет брать через map() или VirtualAlloc() в случае венды или даже тупо кусок памяти на стёке раздавать.

 

4 минуты назад, Tosha сказал:

Например, вторую четверть адресного пространства доступного процессу (третья и четвертая четверть - память ядра) зарезервировать для песочницы и в коде песочницы в любом адресе устанавливать предпоследний бит адреса не давая зайти в нижнюю область. 

Так это опять же особенности венды что она ядро так размещает.

 

Может хватит уже ментального онанизма?)

[Tosha]

7 минут назад, Ivan_83 сказал:

Так это опять же особенности венды что она ядро так размещает.

linux тоже. А собственно и выхода другого нет.  Ядро в середину пихнуть глупо. А в низ - нелогично. 

а в какой ОС из распространенных это не так?

 

7 минут назад, Ivan_83 сказал:

Она и так выделяется страницами по 4кб

Она в разнобой выделяется и не по границам степеней двойки. Для эффективного применения "масок" надо чтобы защищаемая область была одним куском и чтобы в нее ничего лишнего не попало. А защищаемая область - это область процесса. Для 64 бит (где адресация с большим запасом) логично разбить на 2 зоны и два разных аллокатора. Обычной памяти и для "песочницы".

[snvoronkov]

18 минут назад, Tosha сказал:

linux тоже. А собственно и выхода другого нет.  Ядро в середину пихнуть глупо. А в низ - нелогично. 

а в какой ОС из распространенных это не так?

Я только слова для гуглежки накину, ладно?

 

KASLR

 

MIPS linux Highmem vs. EVA

[Tosha]

44 минуты назад, snvoronkov сказал:

KASLR

KASLR это лишь самый защищенный способ как использовать зарезервированную для ядра область памяти. Т.е. не сразу с начала и последовательно, а не с начала, размазано и не по порядку. Это не отменяет принятую с начала систему зонирования виртуальной памяти исполняемых процессов.

Впрочем, если область памяти ядра можно читать - поиск кусков ядра и определение интересных структур - задача посильная. От meltdown не защитит.

Может мы терминологически друг друга не понимаем? В физической памяти ядро может быть где угодно, а в виртуальную память процессов для 64 бит она отображается (в идеале случайным образом) на вторую половину всей доступной виртуальной адресации.

[snvoronkov]

36 минут назад, Tosha сказал:

Может мы терминологически друг друга не понимаем? В физической памяти ядро может быть где угодно, а в виртуальную память процессов для 64 бит она отображается (в идеале случайным образом) на вторую половину всей доступной виртуальной адресации.

Уже нет. Вынесли в отдельное адресное пространство. Причём как на юниксах, так и на форточках.

 

...А ведь ещё в бородатых толи 90-х, толи вообще 80-х моторолловский RISC процессор другого режима работы вообще даже и не предполагал...