Возможно, будет интересно посмотреть на широко известный в узких кругах олимпиадных программистов сайт Codeforces. Он уже давно использует двуязычную модель (ru/en) и, когда я на нём ещё обитал, было ощущение, что он стал чуть ли не популярнее, чем Topcoder. Во всяком случае, так оно изнутри выглядело. :) При этом было немало русскоязычного контента. Мне, например, наиболее интересен вопрос, как быть с комментариями под двуязычной статьёй и как это решено там.
А мне вот интересно, что могут мне "сделать такого гадкого", если я ставлю все обновления ОС. Верно ли, что Meltdown полностью закрывается, а Spectre частично тоже закрывается и намного сложнее в эксплуатации?
А мне подумалось про линуксовую опцию ядра isolcpus — насколько я помню, при загрузке прописываешь, и на указанные ядра процессы можно закидывать только явно. И всё это совершенно бесплатно, прошу заметить. Впрочем, без переключения userspace-kernelspace обойтись всё равно не получится…
А серьёзно, может ли isolcpus каким-то образом защищать от новомодных атак?..
Ах да, насколько я помню, санитайзеры небезопасно использовать в финальной сборке — там, как я понял, упор делался на поиск ошибок в программе, а не на полное отсутствие уязвимостей в рантайме самого санитайзера.
Можно попробовать использовать Undefined Behavior Sanitizer (есть в Clang и GCC). Много всего ищет (но в процессе выполнения, а не статически), хотя, наверное, не всё — например, с дефолтными настройками вызов функции через указатель с неправильной сигнатурой не определяет (это, вроде, UB):
#include <stdio.h>
int f(int x) {
return x + 1;
}
int main() {
int (*fun)(int, int) = (int (*)(int, int)) f;
int x = fun(1, 2);
printf("%d\n", x);
return 0;
}
$ clang -fsanitize=undefined test.c -o test
$ ./test
2
Подозреваю, что не весь UB можно отловить и в рантайме.
Меня со вчерашнего дня мучал вопрос: а если инварианты нашей программы гарантируют, что один из первых четырёх элементов всегда совпадёт — это тоже UB? (Другой вопрос, зачем нам тогда такая функция. Не, ну может, макрос так удачно развернулся...) Например, в такой функции будет UB? — там внутри функции вообще ничего не гарантируется
int get_value_at_index(const int *array, size_t index) {
return array[index];
}
Причем в случае с массивом компилятор сам понимает, что есть UB и оптимизирует(всегда возвращает true). Интересно почему он не производит аналогичную оптимизацию(например, всегда возвращать 0) в случае:
if (table[i] == v) return i;
Я не очень-то стандартовед, но в моём представлении, если за всё время выполнения в программе UB не произойдёт, то она должна отработать по стандарту. Вот если произойдёт, то тогда уже она ничего не обязана (вроде, даже до момента UB).
Всё-таки хочется верить в добрые намерения компилятора, а не "Ух ты, я нашёл UB, сейчас я им устрою". В данном случае (если я не налажал в философии в предыдущем абзаце) в примерах значение, вообще-то, могло и найтись (может, у нас инварианты такие). Но в "булевском" случае всегда, если нет UB, то возвращаемое значение true. То есть в сужении на случай "нет ни одного UB" функция честно константная. А если мы возвращаем индекс, то без UB у нас есть четыре возможных варианта.
Или я понимаю неправильно, и в приведённой функции есть UB, даже если логика программы гарантирует, что аргумент найдётся в первых четырёх элементах массива при любом вызове?
Вероятно, я плохо сформулировал свой комментарий. Когда ребята допишут свою ОС, о CSM, вполне возможно, уже и забудут все. А говорил я вообще про сохранение (пока) поддержки CSM в существующих ОС (на случай ещё достаточно мощного железа, но с древней прошивкой), я не имел в виду, что мне нужна поддержка CSM со стороны прошивки. Ну то есть, кому-то она, может, и нужна, но мне не особо. :) Кстати, читал ваш цикл статей про безопасность UEFI и всё думал: "Как же страшно было жить в 2015" — надеюсь, сейчас всё уже не так плохо? :)
Начинать в 2018 году учебный проект (который в ближайшие три года, может, и на реальном железе ни разу не запустят) с поддержки BIOS, может, и не имеет смысла (кстати, спасибо за ссылку, где указано, как включить поддержку UEFI в QEMU), но вот выкидывать эту поддержку на свалку из реальных продуктов, ИМХО, преждевременно. У меня, например, совсем недавно появился дома первый компьютер с поддержкой UEFI. Нет, я сидел не за еле живой системой, не тянущей ничего современного (про игры, правда, утверждать не буду) — это был вполне живой ноутбук с мобильным Core i3 первого поколения (2 ядра / 4 потока) и 8 Гб оперативки. Я бы, наверное, и ещё пару лет мог бы за ним поработать, машинка вполне мощная. Однако в нём, вроде, ничего кроме классического BIOS не было.
"Истинный программист способен написать операционную систему на Rust даже на ассемблере"? Нет, я понимаю, что это первая, подготовительная, часть из большого цикла, но заголовок забавно сочетается с остальным текстом...
Oracle не планирует обновлять рабочие станцие с Java 8 на более поздние версии через опцию auto update.
И не надо. Хоть у кого-то эта штука "включена"? Не знаю ни одного такого :)
А зачем отключать автообновление (по крайней мере, обычному пользователю)? На случай, если появится регрессии, или есть другие причины?
Лично я столько в своё время наслушался про "Очередная уязвимость в Java, мы все умрём!!!!111", что отключение автообновлений для меня выглядит странно (хотя и не факт, что это и правда создаёт так много опасностей для пользователя при условии, что апплеты отключены). По этой же причине несколько странной выглядит официальная рекомендация разводить на компьютерах пользователей зоопарк устаревших версий.
Например, слышал, что раньше были особенности у как минимум одной из реализаций гибернации: записал в своп состояние памяти, выключился. Захотел включиться и считать память обратно — нужно бы вначале подмонтировать раздел со своп-файлом, но вот незадача: была проблема сделать так, чтобы ядро ну совсем-совсем ничего не исправляло на dirty-разделе — ведь тогда у "восстановленного" ядра будет неконсистентное представление о том, что сейчас на диске. Впрочем, частично ситуация изменилась ещё в декабре 2006 года, судя по логу. А ещё мне очень нравится big fat warning в начале этого файла...
На всякий случай, вот документация. Там много всяких интересных штук, а вот про влияние на безопасность (локальный пользователь прибил lock screen и т.д.) нужно читать где-нибудь в другом месте. Кстати, при работе по ssh до magic sysrq key можно достучаться через /proc/sysrq-trigger, если права позволяют.
Когда-то описывал полезную в этих случаях комбинацию Alt-SysRq-F — принудительно запустить OOM-killer один раз. По умолчанию она (и многие другие сочетания с SysRq) запрещены по соображениях безопасности (по каким именно — нужно читать где-нибудь в первоисточнике), а вообще есть даже сочетание для того, чтобы уронить ядро в kernel panic. :) Это не в качестве замены свопу, а в дополнение (при наличии свопа иногда весьма полезное).
Ну, "открытые исходники для академических нужд" — это всё-таки не "свободные процессоры" и для разработки своего процессора, наверное, далеко не лучший вариант. Хотя, с точки зрения анализа это, конечно, намного лучше, чем ничего.
Реализовано это разделение в x86-семействе аппаратно при помощи сегментной защиты памяти.
Говорят, вместо неё уже давно обычно используются страничная защита. Например, в Википедии про AMD64 написано:
Segmented addressing has long been considered an obsolete mode of operation, and all current PC operating systems in effect bypass it, setting all segments to a base address of zero and (in their 32 bit implementation) a size of 4 GB. AMD was the first x86-family vendor to implement no-execute in linear addressing mode. The feature is also available in legacy mode on AMD64 processors, and recent Intel x86 processors, when PAE is used.
Возможно, будет интересно посмотреть на широко известный в узких кругах олимпиадных программистов сайт Codeforces. Он уже давно использует двуязычную модель (ru/en) и, когда я на нём ещё обитал, было ощущение, что он стал чуть ли не популярнее, чем Topcoder. Во всяком случае, так оно изнутри выглядело. :) При этом было немало русскоязычного контента. Мне, например, наиболее интересен вопрос, как быть с комментариями под двуязычной статьёй и как это решено там.
А мне вот интересно, что могут мне "сделать такого гадкого", если я ставлю все обновления ОС. Верно ли, что Meltdown полностью закрывается, а Spectre частично тоже закрывается и намного сложнее в эксплуатации?
Буквально несколько дней назад видел новость про релиз Qubes 4.0 — не оно? Сам, впрочем, не пользовался.
А мне подумалось про линуксовую опцию ядра
isolcpus— насколько я помню, при загрузке прописываешь, и на указанные ядра процессы можно закидывать только явно. И всё это совершенно бесплатно, прошу заметить. Впрочем, без переключения userspace-kernelspace обойтись всё равно не получится…А серьёзно, может ли
isolcpusкаким-то образом защищать от новомодных атак?..Ах да, насколько я помню, санитайзеры небезопасно использовать в финальной сборке — там, как я понял, упор делался на поиск ошибок в программе, а не на полное отсутствие уязвимостей в рантайме самого санитайзера.
Можно попробовать использовать Undefined Behavior Sanitizer (есть в Clang и GCC). Много всего ищет (но в процессе выполнения, а не статически), хотя, наверное, не всё — например, с дефолтными настройками вызов функции через указатель с неправильной сигнатурой не определяет (это, вроде, UB):
Подозреваю, что не весь UB можно отловить и в рантайме.
Меня со вчерашнего дня мучал вопрос: а если инварианты нашей программы гарантируют, что один из первых четырёх элементов всегда совпадёт — это тоже UB? (Другой вопрос, зачем нам тогда такая функция. Не, ну может, макрос так удачно развернулся...) Например, в такой функции будет UB? — там внутри функции вообще ничего не гарантируется
Я не очень-то стандартовед, но в моём представлении, если за всё время выполнения в программе UB не произойдёт, то она должна отработать по стандарту. Вот если произойдёт, то тогда уже она ничего не обязана (вроде, даже до момента UB).
Всё-таки хочется верить в добрые намерения компилятора, а не "Ух ты, я нашёл UB, сейчас я им устрою". В данном случае (если я не налажал в философии в предыдущем абзаце) в примерах значение, вообще-то, могло и найтись (может, у нас инварианты такие). Но в "булевском" случае всегда, если нет UB, то возвращаемое значение true. То есть в сужении на случай "нет ни одного UB" функция честно константная. А если мы возвращаем индекс, то без UB у нас есть четыре возможных варианта.
Или я понимаю неправильно, и в приведённой функции есть UB, даже если логика программы гарантирует, что аргумент найдётся в первых четырёх элементах массива при любом вызове?
Вероятно, я плохо сформулировал свой комментарий. Когда ребята допишут свою ОС, о CSM, вполне возможно, уже и забудут все. А говорил я вообще про сохранение (пока) поддержки CSM в существующих ОС (на случай ещё достаточно мощного железа, но с древней прошивкой), я не имел в виду, что мне нужна поддержка CSM со стороны прошивки. Ну то есть, кому-то она, может, и нужна, но мне не особо. :) Кстати, читал ваш цикл статей про безопасность UEFI и всё думал: "Как же страшно было жить в 2015" — надеюсь, сейчас всё уже не так плохо? :)
Начинать в 2018 году учебный проект (который в ближайшие три года, может, и на реальном железе ни разу не запустят) с поддержки BIOS, может, и не имеет смысла (кстати, спасибо за ссылку, где указано, как включить поддержку UEFI в QEMU), но вот выкидывать эту поддержку на свалку из реальных продуктов, ИМХО, преждевременно. У меня, например, совсем недавно появился дома первый компьютер с поддержкой UEFI. Нет, я сидел не за еле живой системой, не тянущей ничего современного (про игры, правда, утверждать не буду) — это был вполне живой ноутбук с мобильным Core i3 первого поколения (2 ядра / 4 потока) и 8 Гб оперативки. Я бы, наверное, и ещё пару лет мог бы за ним поработать, машинка вполне мощная. Однако в нём, вроде, ничего кроме классического BIOS не было.
"Истинный программист способен написать операционную систему на Rust даже на ассемблере"? Нет, я понимаю, что это первая, подготовительная, часть из большого цикла, но заголовок забавно сочетается с остальным текстом...
А зачем отключать автообновление (по крайней мере, обычному пользователю)? На случай, если появится регрессии, или есть другие причины?
Лично я столько в своё время наслушался про "Очередная уязвимость в Java, мы все умрём!!!!111", что отключение автообновлений для меня выглядит странно (хотя и не факт, что это и правда создаёт так много опасностей для пользователя при условии, что апплеты отключены). По этой же причине несколько странной выглядит официальная рекомендация разводить на компьютерах пользователей зоопарк устаревших версий.
Это радует… А "эти" — это начального уровня, так сказать, "не очень мощные", или просто которые не SDR?
Интересно, а на отладочные платы, скажем, что-то типа такого, нотификация нужна?
Например, слышал, что раньше были особенности у как минимум одной из реализаций гибернации: записал в своп состояние памяти, выключился. Захотел включиться и считать память обратно — нужно бы вначале подмонтировать раздел со своп-файлом, но вот незадача: была проблема сделать так, чтобы ядро ну совсем-совсем ничего не исправляло на dirty-разделе — ведь тогда у "восстановленного" ядра будет неконсистентное представление о том, что сейчас на диске. Впрочем, частично ситуация изменилась ещё в декабре 2006 года, судя по логу. А ещё мне очень нравится big fat warning в начале этого файла...
Как там кофемашины говорят, "Опорожните поддон для капель"...
На всякий случай, вот документация. Там много всяких интересных штук, а вот про влияние на безопасность (локальный пользователь прибил lock screen и т.д.) нужно читать где-нибудь в другом месте. Кстати, при работе по ssh до magic sysrq key можно достучаться через
/proc/sysrq-trigger, если права позволяют.Когда-то описывал полезную в этих случаях комбинацию Alt-SysRq-F — принудительно запустить OOM-killer один раз. По умолчанию она (и многие другие сочетания с SysRq) запрещены по соображениях безопасности (по каким именно — нужно читать где-нибудь в первоисточнике), а вообще есть даже сочетание для того, чтобы уронить ядро в kernel panic. :) Это не в качестве замены свопу, а в дополнение (при наличии свопа иногда весьма полезное).
Ну, "открытые исходники для академических нужд" — это всё-таки не "свободные процессоры" и для разработки своего процессора, наверное, далеко не лучший вариант. Хотя, с точки зрения анализа это, конечно, намного лучше, чем ничего.
Говорят, вместо неё уже давно обычно используются страничная защита. Например, в Википедии про AMD64 написано: