Сообщение Re[13]: Отдыхаете ли вы на работе ? от 16.10.2019 14:48
Изменено 16.10.2019 20:11 IID
Re[13]: Отдыхаете ли вы на работе ?
Здравствуйте, okon, Вы писали:
O>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.
CAF>>Примеры в студию?
O>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.
Очевидно, что это совсем нетривиальная область.
Большое число последних багов в Linux ядре — из-за гонок (Race conditions).
Их пытаются ловить весьма крутым инструментом, Syzkaller-ом, который пишет небезызвестный remark. И всё равно находятся новые.
Варианта, собственно, два:
— Или обвешиваем всё мьютексами и прощаемся с производительностью
— Или пытаемся использовать Lock-free и локальные кеши per-CPU. Пишем быстрый, но сложный код, в котором заводятся баги.
А иногда бывает что нету ни того, ни другого
Пример — у гонки окно всего в несколько сотен тактов процессора, т.е. десятые доли микросекунды. А позволяет исполнить код в ядре на всех буханках вплоть до конца 2017 года. Т.е. получить максимальнейшие привилегии, обойдя все SW защиты (DAC, MAC, SECCOMP) и HW защиты (NX, SMAP, SMEP).
O>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.
CAF>>Примеры в студию?
O>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.
Очевидно, что это совсем нетривиальная область.
Большое число последних багов в Linux ядре — из-за гонок (Race conditions).
Их пытаются ловить весьма крутым инструментом, Syzkaller-ом, который пишет небезызвестный remark. И всё равно находятся новые.
Варианта, собственно, два:
— Или обвешиваем всё мьютексами и прощаемся с производительностью
— Или пытаемся использовать Lock-free и локальные кеши per-CPU. Пишем быстрый, но сложный код, в котором заводятся баги.
А иногда бывает что нету ни того, ни другого
Пример — у гонки окно всего в несколько сотен тактов процессора, т.е. десятые доли микросекунды. А позволяет исполнить код в ядре на всех буханках вплоть до конца 2017 года. Т.е. получить максимальнейшие привилегии, обойдя все SW защиты (DAC, MAC, SECCOMP) и HW защиты (NX, SMAP, SMEP).
Re[13]: Отдыхаете ли вы на работе ?
Здравствуйте, okon, Вы писали:
O>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.
CAF>>Примеры в студию?
O>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.
Очевидно, что это совсем нетривиальная область.
Большое число последних багов в Linux ядре — из-за гонок (Race conditions).
Их пытаются ловить весьма крутым инструментом, Syzkaller-ом, который пишет небезызвестный remark. И всё равно находятся новые.
Варианта, собственно, два:
— Или обвешиваем всё мьютексами и прощаемся с производительностью
— Или пытаемся использовать Lock-free и локальные кеши per-CPU. Пишем быстрый, но сложный код, в котором заводятся баги.
А иногда бывает что нету ни того, ни другого
Пример — у гонки окно всего в несколько сотен тактов процессора, т.е. десятые доли микросекунды. А позволяет исполнить код в ядре на всех буханках вплоть до конца 2017 года. Т.е. получить максимальнейшие привилегии, обойдя все SW защиты (DAC, MAC, SECCOMP) и HW защиты (NX, SMAP, SMEP).
А вот пример особо эпичной гонки. Конец 2016 года, около 10 лет багу, много лет эксплуатировался хакерами In-the-wild (собственно был пойман после атаки, благодаря логгированию всего сетевого трафика)
Окно — буквально две соседние инструкции. Но мощь при этом невероятная — получаем доступ на запись во все места, к которым имеем доступ на чтение. Причём в буханках /proc/mem это тоже файл, а значит мы можем локально изменить libc, и изменения моментально окажутся ВО ВСЕХ работающих процессах. Включая работающие под root. Баг не требует адаптации под конкретную версию-архитектуру-смещения в коде, работал абсолютно на всех буханках, даже из скриптовых языков — у современных компьютеров достаточно мощности.
Дополнительную пикантность багу придаёт то, что его внёс лично глав-петух Торвальдс. Не осилив починить другой баг.
O>>>Зря ты думаешь что никто не умеет это хорошо делать, мне кажется по этой теме есть достаточно специалистов. Параллелизм известен давно и тестирование.
CAF>>Примеры в студию?
O>Набери testing multithreading code и получишь ответ, очевидно что уже много людей за много лет на этом собаку съели и есть те кто знает что делать в твоем случае.
Очевидно, что это совсем нетривиальная область.
Большое число последних багов в Linux ядре — из-за гонок (Race conditions).
Их пытаются ловить весьма крутым инструментом, Syzkaller-ом, который пишет небезызвестный remark. И всё равно находятся новые.
Варианта, собственно, два:
— Или обвешиваем всё мьютексами и прощаемся с производительностью
— Или пытаемся использовать Lock-free и локальные кеши per-CPU. Пишем быстрый, но сложный код, в котором заводятся баги.
А иногда бывает что нету ни того, ни другого
Пример — у гонки окно всего в несколько сотен тактов процессора, т.е. десятые доли микросекунды. А позволяет исполнить код в ядре на всех буханках вплоть до конца 2017 года. Т.е. получить максимальнейшие привилегии, обойдя все SW защиты (DAC, MAC, SECCOMP) и HW защиты (NX, SMAP, SMEP).
А вот пример особо эпичной гонки. Конец 2016 года, около 10 лет багу, много лет эксплуатировался хакерами In-the-wild (собственно был пойман после атаки, благодаря логгированию всего сетевого трафика)
Окно — буквально две соседние инструкции. Но мощь при этом невероятная — получаем доступ на запись во все места, к которым имеем доступ на чтение. Причём в буханках /proc/mem это тоже файл, а значит мы можем локально изменить libc, и изменения моментально окажутся ВО ВСЕХ работающих процессах. Включая работающие под root. Баг не требует адаптации под конкретную версию-архитектуру-смещения в коде, работал абсолютно на всех буханках, даже из скриптовых языков — у современных компьютеров достаточно мощности.
Дополнительную пикантность багу придаёт то, что его внёс лично глав-петух Торвальдс. Не осилив починить другой баг.