URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 132646
[ Назад ]
Исходное сообщение
"Оценка эффективности применения MiraclePtr для предотвращения уязвимостей в Chrome "
Отправлено opennews , 23-Янв-24 16:23 
Компания Google проанализировала эффективность использования в коде на языке С++ типа MiraclePtr (raw_ptr‹T›) вместо обычных указателей для защиты от  уязвимостей, вызванных обращением к уже освобождённым областям памяти (use-after-free). MiraclePtr предоставляет обвязку над указателями, выполняющую дополнительные проверки и аварийно завершающую работу в случае обнаружения обращения к освобождённым областям памяти. Поддержка MiraclePtr была включена по умолчанию на платформах Windows и Android в мае 2022 года (в Chrome 102), а на платформах ChromeOS, Linux и macOS в июне 2023 года. Защита на базе MiraclePtr в  Chrome применяется для всех процессов, кроме процесса, отвечающего за отрисовку (renderer)...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60482

Содержание
Сообщения в этом обсуждении
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 16:23 
В общем Чуда не произошло.
Накладные расходы в 5.5-8% потребления памяти и торможение на 1.5% думаю допустимы, но неприятны.
Особенно учитывая улучшение 'немного лучше 50%' - "защиту от 57% уязвимостей класса use-after-free"

Может после этого попросят андроид команду поделиться опытом испроьзования Rust.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено _kp , 23-Янв-24 16:50 
А в Rust безопасный код типа только при компиляции проверяется?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 23:08 
Можно было уже прочитать хотя бы википодию.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 22:59 
не читайте во время еды, там есть примеры синтаксиса
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 25-Янв-24 03:23 
Если бы ты сам почитал хотя бы википедию, то знал бы, что во время выполнения программы также выполняются некоторые проверки безопасности. Например, при обращении к срезам (slices) или использовании небезопасных функций и блоков кода, Rust может проверять индексы, границы массивов и другие условия безопасности. Естественно, небесплатно.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 20:08 
> Может после этого попросят андроид команду поделиться опытом испроьзования Rust.

Так поделились же год назад. Надо свежЕе? Предполагаю не сильно статистика поменялась. Кратко: в андроидовском раст-коде ошибок работы с памятью (это не только use-after-free, но и всякие выходы за границы буфера, двойное освобождение и прочее ) - ровно ноль. Это в 1.5 млн строк кода разных системных компонент, 21% всего нового нативного кода системы. Собираются и дальше выкидывать си/плюсы и внедрять больше раста. Уже даже посматривают и облизываются на раст-подсистему, создаваемую в линукс-ядре. Короче, очень довольны растом:

https://security.googleblog.com/2022/12/memory-safe-language...

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 20:19 
Не, рамарка была про "андроид команда своими программерами делиться не захочет, а своих еще переучить нужно или новых набрать".

С другой стороны, я видел их отчет по поводу "Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022"
и там людей с переучивали весьма быстро.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Прадед , 25-Янв-24 02:11 
Вообщетики двойное освобождение тоже юз афта фри
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 20:24 
57% это даже не стакан на половину пуст, а пуст на 7 % меньше чем на половину
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Минона , 23-Янв-24 22:27 
Fields Medal этому господину!
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 24-Янв-24 11:51 
> стакан на половину пуст

Стакан априори пуст (с завода-изготовителя). Если в нём что-то есть, значит, его наполняли. То есть единственно верная оценка: стакан наполовину полон. Кто заявляет обратное, у того проблемы с пониманием проходящего.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 23:00 
> Может после этого попросят андроид команду поделиться опытом испроьзования Rust.

думаю, просто перейдут на firefox

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Бывалый смузихлёб , 25-Янв-24 10:47 
> внедрение MiraclePtr предоставило защиту от 57% уязвимостей класса use-after-free
> для указателей требуется хранить дополнительные 4 байта со счётчиком ссылок

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

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено anonymmm , 23-Янв-24 16:34 
The owner of the memory must free it when the time is right, don‘t assume raw_ptr<T> will free it for you (it won’t). Unlike std::unique_ptr<T>, base::scoped_refptr<T>, etc., it does not manage ownership or lifetime of an allocated object.
if the pointer is the owner of the memory, consider using an alternative smart pointer.


Так я не понял, а почему они просто std::unique_ptr и прочие smart указатели из стандартной библиотеки не используют.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено topin89 , 23-Янв-24 16:53 
Как ни странно, даже unique_ptr'ы небесплатные: https://youtu.be/rHIkrotSwcc?t=1054
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 23:08 
А миракл птр бесплатное?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 24-Янв-24 11:55 
Это психологический треннинг? Если пример кода (на 19:32) поместить в реальный мир, то foo() будет встроена, с соответствующей оптимизацией.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 23:07 
ну да, нафиг стандарты. аноним гарантирует, что "будет встроена"
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 25-Янв-24 10:10 
Аноним пусть делает, что хочет. Я велосипедил std::unique_ptr<> до принятия в стандарт и очень внимательно изучал генерируемые MSVC 7-й версии листинги. Потому для себя выводы сделал ещё тогда, а с тех пор оптимизаторы шагнули вперёд. Пользуясь случаем, передаю привет секте свидетелей экономии углеродного следа за счёт разделяемых библиотек.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 23-Янв-24 16:56 
это аналоги обычных std-шных указателей, только с тормозными проверками, принудительным падением и крешдампом
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено unix greybeard , 23-Янв-24 19:22 
Вероятно для этого придется переписывать слишком много кода. А так можно просто заменить обычные указатели на raw_ptr и заиметь Профит.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено mister_0 , 23-Янв-24 23:52 
но если всё переписать на unique, shared и weak ptrs, то double free и use after free станут невозможными, разве это не профит???
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 00:51 
разыменовывать нулевые smart pointers законом запретили? кажется, я что-то пропустил
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено anonymmm , 24-Янв-24 12:08 
такое разименование легко заменить, процесс грохнется с pagefault, проблема же, что используются адреса, по которым уже освобождён объект и состояние памяти в неизвестном состоянии.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 24-Янв-24 12:17 
> используются адреса, по которым уже освобождён объект

Очень хочется увидеть пример кода для unique_ptr<>.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 24-Янв-24 12:15 
> разыменовывать нулевые smart pointers законом запретили?

20.11.1.2.4  Observers  [unique.ptr.single.observers]

add_lvalue_reference_t<T> operator*() const;

1 Preconditions: get() != nullptr.

2 Returns: *get().


16.5.4.11  Expects paragraph  [res.on.expects]

1 Violation of any preconditions specified in a function’s Preconditions: element results in undefined behavior.

> кажется, я что-то пропустил

Совершенно точно. Момент, когда программистов заменили на пользователей библиотек и упаковщиков кода.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 12:32 
> 1 Violation of any preconditions specified in a function’s Preconditions: element results in undefined behavior.

ты такой остряк, в квн не пробовал выступать?

специально для тебя разжую: что мешает ошибочно или специально разыменовать нулевой автоматический указатель? выше написано "то double free и use after free станут невозможными," - в каком месте use after free станет невозможным?

с появлением поколения "тред не читал, комментить побежал" мы и заимели electron и rust

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 24-Янв-24 17:23 
>> 1 Violation of any preconditions specified in a function’s Preconditions: element results in undefined behavior.
> ты такой остряк, в квн не пробовал выступать?
> специально для тебя разжую: что мешает ошибочно или специально разыменовать нулевой автоматический
> указатель?

Тебе ничего не мешает. Я могу это запретить - мне это разрешил стандарт:

3.30  [defns.undefined]  undefined behavior

behavior for which this document imposes no requirements

[Note 1 to entry: Undefined behavior may be expected when this document omits any explicit definition of
behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the environment (with or without the issuance
of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed.
Evaluation of a constant expression never exhibits behavior explicitly specified as undefined in Clause 4
through Clause 15 of this document (7.7). — end note]

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 20:38 
> Тебе ничего не мешает. Я могу это запретить - мне это разрешил стандарт:

ясно, ты тугенький на отсутствующий ум. даже не знаю, можно ли такому овощу слив засчитать

> в каком месте use after free станет невозможным?

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

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 25-Янв-24 10:25 
>>>> разыменовывать нулевые smart pointers законом запретили?
>>> 1 Preconditions: get() != nullptr.
>> в каком месте use after free станет невозможным?
> у тебя ещё со зрением проблемы

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

И передёргивать #43 ты принялся совершенно напрасно, поскольку автор, в отличие от тебя, умеет читать стандарт:

20.11.1.2.5  Modifiers  [unique.ptr.single.modifiers]

pointer release() noexcept;

1 Postconditions: get() == nullptr.

2 Returns: The value get() had at the start of the call to release.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено anonymous , 25-Янв-24 10:41 
Им раньше shared/unique ptr использовать религия не позволяла. Им их совсем недавно разрешили использовать (где-то в конце 2010-х).
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 16:38 
Эффективность оценили, а приемлемость? Веб приложения и так работают небыстро.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 16:59 
"Просто обновите себе комп", как говорил Тодд-купи-скайрим-Говард)
С учетом развития железа, просто поставят в новый хромбук процессор на 5% мощнее.
Ну и скажут 'минимум 8/16 гигов оперативки'.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 22:27 
> просто поставят в новый хромбук процессор на 5% мощнее

На 3%, не более: жирный софт должен тормозить.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 17:43 
> Веб приложения и так работают небыстро.

Можешь конкретные урлы назвать или так, от пацанов во дворе слышал?

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Самый Лучший Гусь , 23-Янв-24 19:06 
Веб приложения работают достаточно быстро на современном железе. Я имею в виду железо хотя бы не старше 2014 года (Lenovo ThinkPad T440p)
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Mr.Who , 23-Янв-24 17:26 
Гугель сегодня самая отвратительная и грязная контора во всём IT. Майкрософт на их фоне просто невинные дети.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 17:38 
Какие ваши доказательства?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 17:42 
Как ты смеешь так говорить о платинновых спонсорах Linux Foundation, локомотивах развития опенсорса и вооьще классных ребятах!
Нужели ты хочешь сам писать код, а не пользоваться трудом программеров на зарплате?!
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 19:46 
Согласен. Послал как-то им патч, устраняющий memory-safety проблему (реальную, у меня прога крашнулась на ней) в их утилите. Они мне: проходи идентификацию, принимай CLA. Я им: никаких CLA, CLA - зло, лицензирую код под ОД, CLA подписывать не буду, хотите прининимайте, не хотите - не принимайте. Так патч и не приняли.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено ox , 23-Янв-24 18:43 
> для защиты от уязвимостей, вызванных обращением к уже освобождённым областям памяти

Может, учебник по С++ почитать?

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 19:01 
какой посоветуете?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 00:44 
How to program c++, Харви Дейтел, Пол Дейтел (одно из первых изданий, жёлтая обложка), там хорошо объясняются актуальные до сих основы языка и вообще программирования (у меня до сих пор переводы систем счисления от зубов отскакивают), чего нет в новых изданиях

Deitel P., Deite H. C++20 for Programmers 3ed 2021

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

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

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 19:08 
И как это поможет от обычных человеческих ошибок? Или ты из тех самых «настояших сишников», которые ошибок никогда не допускают?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 19:22 
Ты сначала научись отличать си плюс-плюсника от чистосишника.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 00:46 
уже лет двадцать народ сначала учит плюсы, потом си
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Карлос Сношайтилис , 23-Янв-24 19:25 
Zero-cost абстракции, говорили они
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Минона , 23-Янв-24 22:32 
Это в расте говорили.
В плюсах их нет.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 00:47 
это как бы основная фишка плюсов, есличо
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Минона , 24-Янв-24 14:11 
> это как бы основная фишка плюсов, есличо

Основная фишка С/С++ - UB.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено 12yoexpert , 24-Янв-24 16:04 
кто ж вас, детей, так запугал этим UB? из каждого утюга о нём кукарекаете
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено n00by , 24-Янв-24 17:36 
> кто ж вас, детей, так запугал этим UB?

Вон в #62 эксперт меня пугал.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 25-Янв-24 09:47 
Пугает время на поиск и отладку проблемы, потраченные нервы пользователей, не говоря уже возможных финансовых и репутационных потерях. Хеловорды конечно можно абыкак и на абычом писать.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Минона , 25-Янв-24 15:26 
> кто ж вас, детей, так запугал этим UB? из каждого утюга о
> нём кукарекаете

Сам создатель.

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Карлос Сношайтилис , 26-Янв-24 21:14 
В расте сделали, а в плюсах говорили. Не перепутай
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 19:40 
>так как для указателей требуется хранить дополнительные 4 байта со счётчиком ссылок.

Чем это отличается от std::shared_ptr?

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 20:49 
Для shared_ptr хранить нужно больше, да ещё по умолчанию и в отдельном чанке памяти, Садись, два
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено mister_0 , 23-Янв-24 23:53 
с shared будет 100% багов пофикшено, а так только 57% остальные для performance review на следующий год
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 24-Янв-24 12:48 
Передача указателя по указателю может же быть не просто так. Собственно, вопрос чтобы вытянуть на троекчку: какая новая бага может появиться, если все такие сырые указатели заменить на shared_ptr сссылки?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено anonymous , 25-Янв-24 11:42 
О каких таких сырых указателях идет речь? Гугл использует собственную реализацию shared_ptr, вопрос заключался в том, а почему сразу не использовать их вместо собственной реализации неизвестного радиуса кривизны?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 25-Янв-24 21:16 
Гугл может и использует свою реализацию google::shared_ptr, как и многие другие древние компании, т.к. гугл существует много дольше чем с++11 с std::shared_ptr. Однако научить же читать, выше речь не о shared_ptr.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 25-Янв-24 18:07 
std::make_shared<T>() хранит всё в одном чанке.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено лютый жабби.... , 23-Янв-24 20:51 
хромоног просто ужасен - запускаю его всегда из консоли, за несколько часов "работы" несколько экранов всяких failed, unable итд.... а периодически закрывается с сегфолтом.

хромиум что дебианий, что арчевский - один фиг. значит не в сборщиках дело, а в косом гугле

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 20:57 
Ну запусти теперь так ФФ. У него уже, например, несколько десятков последних релизов табы зависают
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Печенька , 23-Янв-24 22:13 
> Кроме того, при использовании MiraclePtr зафиксированы отдельные регрессии, приводящие к снижению производительности, но не связанные с ключевыми метриками, такими как время загрузки и отрисовки страницы.

Я может что не понимаю, но какая метрика ключевая для программы, которая загружает и отрисовывает страницы?

"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 22:29 
А отстукивать в гугло-сервисы кто будет?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Минона , 23-Янв-24 22:36 
Гугель, зачем страдать, переписывайте движок на расте!
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 23-Янв-24 23:42 
Так может тогда просто взять Vala?
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 24-Янв-24 05:46 
Не даром же говорят «не е… вола».
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Прадед , 25-Янв-24 02:19 
Слишком изысканно
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 24-Янв-24 08:55 
30 придумывают разные виды указателей, и угомониться никак не могут, и даже расширили синтаксис метапрограммирования. Вот уж действительно С++ - это Си на костылях. Вместо того, что бы переложить управление памятью на среду выполнения, они непрерывно создают макросы для реализации очередной разновидности указателей, которые "ни такие как те, что были раньше, а намного лучше и безопаснее".
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено tty0 , 24-Янв-24 09:21 
Вместо того, чтобы переложить мыслительный процесс на человека, продолжают говнокодить и терять указатели.
Ошибки и опечатки случаются, но искать их должен компилятор. И не так как в расте.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Tron is Whistling , 24-Янв-24 23:20 
Miracl'ов не бывает. Потеря производительности кстати копеечная.
"Оценка эффективности применения MiraclePtr для предотвращени..."
Отправлено Аноним , 25-Янв-24 03:20 
>While there are performance costs associated with the implementation of MiraclePtr, our analysis suggests that the benefits in terms of security improvements far outweigh these. We are committed to continually refining and expanding the feature to cover more areas.

Короче гуглятам понравилось, будут пользоватся. Еще бы, половина проблем с памятью решена почти бесплатно, память сейчас дешевая.