А в ней можно создать блок больше размера страницы? Просто 4КБ это ограничения из-за страничного кэша используемого в vfs linux kernel, а xfs как и все файловые системы "подключены" через vfs к ядру.
Звучит так как будто это делают специально. Прямо выделенный разработчик работает над задачей сломать драйверы к релизу X.
ИМХО просто драйверы составляют огромную часть ядра Linux, и все время приходят новые драйверы, изменения в существующих и т.д., чтобы не рухнуть в пучину костылей, что с такой огромной кодовой базой будет прямой путь на дно, нужно время от времени рефакторить и вписывать в общую архитектуру новые фичи новых устройств. Что неминуемо ведет к "слому" имеющегося ядреного API.
Непонятно при чем здесь Россия. Ну не сможет OneWeb работать в РФ легально,
это настолько большой рынок чтобы переживать, а тем более это как-то могло повлиять на банкротство?
Ну в случае с Rust было бы лучше, но не совсем. То есть ясно
что упали с "index out of bounds" и ясно про какой индекс и массив
идет речь, но если при расчете индекса использовалось с десяток арифметических
операций и каждый раз использовались какие-то сторонние данные,
то разобраться тоже будет не просто откуда у нас взялся такой странный индекс. То есть да, все будет на порядок проще и безопаснее, но все проблемы не исчезнут при переписывании как мановению волшебной палочки..
Я слушаю подкасты когда гуляю с собакой. Наверное еще за рулем можно слушать. Странно это рассматривать как замена чтению, всего лишь дополнение когда читать физически не возможно.
Походу пора все переписывать на rust, чтобы уже закрыть вопросы с подобными проблемами
Rust не решит кардинально эту проблему. Судя по патчу исправляющему уязвимость,
основная проблема это арифметическое переполнение. Такого рода проблемы детектируются только в отладочной сборке программы на Rust. Так что смещение в буфере (или что там вычисляется) было одинаково с ошибкой вычислено в Rust и в C. Другой вопрос, что при обращению по этому смещению программа на Rust упала бы из-за panic, а не позволила бы использовать арифметическое переполнение для "получения root". То есть уязвимость была конечно намного менее неприятна — DDoS вместо root, но все равно бы была.
Так в браузере достаточно огрубить функции измерения времени, чтобы нельзя было заметить разницу в использовании кэша/предсказателя переходов и т.д и т.п.,
и все эти уязвимости станут не актуальны, разве нет?
Ну, sort of — через добавление костыля в виде опционального флага
Э… ну насколько я знаком с разработкой rustc это не так. Флаги начинающиеся -Z это так называемые фича флаги, они работают только в альфа/ночном релизе и служат для тестирования новых идей. В данном случае насколько исправление замедляет код тестеров. При запуске со стабильной версией компилятор просто скажет или выругается или просто проигнорирует '-Z" опции.
в ряде сценариев работы с числами с плавающей точкой заруливается в минуса
Ну вообще каждая функция объявленная как static в таком огромном
проекте это благо. Это и ускоряет компиляцию и линковку, и упрощает поддержку, так как чем меньше функций доступных извне данной единицы трансляции тем меньше межмодульных связей, и думаю очевидна польза от уменьшения связанности огромного проекта?
Но почему? Конкуренты обгонят в нумерацию, если следующую версию после 81 назвать 82?
А в ней можно создать блок больше размера страницы? Просто 4КБ это ограничения из-за страничного кэша используемого в vfs linux kernel, а xfs как и все файловые системы "подключены" через vfs к ядру.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/libxfs/xfs_sb.c?h=v5.6-rc7#n356
Звучит так как будто это делают специально. Прямо выделенный разработчик работает над задачей сломать драйверы к релизу X.
ИМХО просто драйверы составляют огромную часть ядра Linux, и все время приходят новые драйверы, изменения в существующих и т.д., чтобы не рухнуть в пучину костылей, что с такой огромной кодовой базой будет прямой путь на дно, нужно время от времени рефакторить и вписывать в общую архитектуру новые фичи новых устройств. Что неминуемо ведет к "слому" имеющегося ядреного API.
Непонятно при чем здесь Россия. Ну не сможет OneWeb работать в РФ легально,
это настолько большой рынок чтобы переживать, а тем более это как-то могло повлиять на банкротство?
Это ведь нарушение стандарта?
https://en.cppreference.com/w/cpp/language/identifiers
Ну в случае с Rust было бы лучше, но не совсем. То есть ясно
что упали с "index out of bounds" и ясно про какой индекс и массив
идет речь, но если при расчете индекса использовалось с десяток арифметических
операций и каждый раз использовались какие-то сторонние данные,
то разобраться тоже будет не просто откуда у нас взялся такой странный индекс. То есть да, все будет на порядок проще и безопаснее, но все проблемы не исчезнут при переписывании как мановению волшебной палочки..
Я слушаю подкасты когда гуляю с собакой. Наверное еще за рулем можно слушать. Странно это рассматривать как замена чтению, всего лишь дополнение когда читать физически не возможно.
Rust не решит кардинально эту проблему. Судя по патчу исправляющему уязвимость,
основная проблема это арифметическое переполнение. Такого рода проблемы детектируются только в отладочной сборке программы на Rust. Так что смещение в буфере (или что там вычисляется) было одинаково с ошибкой вычислено в Rust и в C. Другой вопрос, что при обращению по этому смещению программа на Rust упала бы из-за panic, а не позволила бы использовать арифметическое переполнение для "получения root". То есть уязвимость была конечно намного менее неприятна — DDoS вместо root, но все равно бы была.
Deleted
Так в браузере достаточно огрубить функции измерения времени, чтобы нельзя было заметить разницу в использовании кэша/предсказателя переходов и т.д и т.п.,
и все эти уязвимости станут не актуальны, разве нет?
Есть такая прикольная штука, правда лично не пользовался:
https://www.youtube.com/watch?v=6LNR8u19x6Y&feature=emb_title
Вот есть неплохая статья с описанием как настраивать ядро Linux:
http://engineering.pivotal.io/post/virtual_memory_settings_in_linux_-_the_problem_with_overcommit/
Чему завидовать или пару ноликов забыли дописать?
Э… ну насколько я знаком с разработкой rustc это не так. Флаги начинающиеся
-Zэто так называемые фича флаги, они работают только в альфа/ночном релизе и служат для тестирования новых идей. В данном случае насколько исправление замедляет код тестеров. При запуске со стабильной версией компилятор просто скажет или выругается или просто проигнорирует '-Z" опции.Увидел только один вариант который замедлился i128 -> f32, но и его исправили:
https://github.com/rust-lang/rust/pull/67328
Так они же это исправили?
А можно про это поподробнее?
Э… это чтобы его супермен не отодрал от ворот?
Ага, а если вы еще сами (вместо нас) будете возить посылки и письма и пункта А в пункт Б,
то вообще цены вам не будет.
Вопрос скорее почему они раньше не закрылись? В центре цены за аренду зашкаливают, как они раньше-то держались?
Ну вообще каждая функция объявленная как static в таком огромном
проекте это благо. Это и ускоряет компиляцию и линковку, и упрощает поддержку, так как чем меньше функций доступных извне данной единицы трансляции тем меньше межмодульных связей, и думаю очевидна польза от уменьшения связанности огромного проекта?