The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

70% проблем с безопасностью в Chromium вызваны ошибками при ..., opennews (ok), 24-Май-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


90. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +3 +/–
Сообщение от Ordu (ok), 24-Май-20, 16:31 
Это в простейшем случае. Но прикинь теперь, что, допустим, у тебя есть гуй, который представляется в памяти в виде дерева виджетов. Каждый виджет представлен кусоком памяти, на который в этом дереве есть ровно один указатель. Теперь представь, что среди этих виджетов есть кнопка, и ты вешаешь обработчик на эту кнопку, например, это может быть замыкание, которое захватило указатель на кусок памяти представляющий эту кнопку. Или, если нефункционально зато в стиле ООП, то это будет объект, который имеет метод onclick, и поле button, хранящее указатель на эту кнопку. Этот объект-замыкание мы засовываем в наш менеджер ивентов. И вот ты решил удалить кнопку, сделал на неё free, а тут прилетел onclick event, и объект-замыкание сделало use-after-free.
Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

98. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от анононимчик (?), 24-Май-20, 16:40 
Такие проблемы были давным давно решены и в Delphi/Pascal, и в MFC, и в Qt.
Ответить | Правка | Наверх | Cообщить модератору

103. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +3 +/–
Сообщение от Ordu (ok), 24-Май-20, 16:54 
Какие именно проблемы из перечисленных были решены?

Я спросил у гугла про qt + use-after-free и тут же он нашёл мне:
https://nvd.nist.gov/vuln/detail/CVE-2020-12267
https://bugreports.qt.io/browse/QTBUG-60786
https://bugreports.qt.io/browse/QTBUG-62443

Ты можешь сам поискать ещё, если тебе мало. qt точно так же ходит по граблям use-after-free как и все остальные.

Насчёт Delphi/Pascal я не уверен, я никогда не писал на них сколь-нибудь серьёзно, но загуглил и вот что нашёл: https://wiert.me/2020/01/20/delphi-a-few-notes-on-tracking-d.../
Что наводит на мысль о том, что в Delphi тоже вполне возможно наступить на use-after-free.

Где надо вызывать free -- это очень сложный вопрос, на который не всегда можно ответить статически, иногда ответ надо искать динамически. Если при этом нет жёсткой системы, которая позволяет, хотя бы, отличить одно от другого, и которая ругается при компиляции о том, что в коде не очевидно где нужно вызывать free, то программисты будут вызывать free не там где надо.

ps. Да и в любом случае -- решены или не решены, -- всё равно ситуация оказывается резко сложнее, чем описывает ТС.

Ответить | Правка | Наверх | Cообщить модератору

419. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Андрей (??), 26-Май-20, 03:20 
> Где надо вызывать free -- это очень сложный вопрос, на который не всегда можно ответить статически, иногда ответ надо искать динамически.

К счастью, в автоматизации этого направления делаются успехи. Две недели назад была новость:

https://www.opennet.ru/opennews/art.shtml?num=52903
> Релиз набора компиляторов GCC 10
> Основные изменения:
> Добавлен экспериментальный режим статического анализа "-fanalyzer", который выполняет ресурсоёмкий межпроцедурный анализ путей выполнения кода и потоков данных в программе. Режим способен на этапе компиляции выявлять такие проблемы, как ... обращение к освобождённым блокам памяти, ... Применение нового режима для кода OpenSSL уже позволило выявить опасную уязвимость. https://www.opennet.ru/opennews/art.shtml?num=52782

Ответить | Правка | Наверх | Cообщить модератору

420. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Совершенно другой аноним (?), 26-Май-20, 08:44 
И до этого были такие программы, как cppcheck, Pvs-studio и куча других. И в clang есть встроенный статический анализатор, некоторым даже нравится, но как сказал предыдущий оратор - всё не так просто. Опять-же до C11 основным императивом языка С было - программист знает, что делает. Т.е. если хочет стрельнуть в ногу - пусть стреляет, может ему так надо. Сейчас это немного поменялось. Хотя по-мне - подход был правильный, просто при этом действительно наращивать разные анализаторы и прочее. Т.е. хотите скорость, для критичных именно по скорости вещей - вам нужен Assembler, C, C++. Нужна безопасность - берите другой язык, ту-же Java.
Ответить | Правка | Наверх | Cообщить модератору

433. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 26-Май-20, 14:43 
>> Где надо вызывать free -- это очень сложный вопрос, на который не всегда можно ответить статически, иногда ответ надо искать динамически.
> К счастью, в автоматизации этого направления делаются успехи.

Да, успехи делаются. Но если ты попробуешь раст, ты увидишь где эти успехи заканчиваются. Борроу-чекер может вычислить много чего, но он ограничивает. Иногда очень болезненно. Например, есть у меня структура, в ней много нодов. Допустим, каждый нод содержит int. Я хочу получить N нодов (для выбора каждого нода у меня своё правило), после чего провернуть какие-то манипуляции над ними, которые изменят все эти N нодов. То есть я хочу прописать в каждый нод новое значение, которое будет вычислено на основании текущих значений в этих N нодах.

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

Ограничение на количество активных мутабельных указателей нужно, потому что благодаря этому ограничению обеспечивается консистентность памяти. Но на выходе я получаю гемморрой на, казалось бы, ровном месте: в моём случае никак не могут возникнуть проблемы с консистентностью памяти, даже если я расчехлю unsafe и сделаю это в C'шном стиле. Я это знаю, но борроу-чекер не видит этого.

Борроу-чекер работает как задумано лишь в относительно простых случаях. Да этих случаев -- подавляющее большинство, но всё равно появляются такие случаи, в которых надо либо отключать borrow-checker unsafe'ом и думать своей головой, либо городить огород мозголомных API для решения простых задач.

В языке не заточенном под борроу-чекер ситуация будет иной. Как получится -- зависит от языка и реализации. Возможно ты получишь такой поток ложных варнингов, что обязательно пропустишь в них парочку варнингов по делу. Может быть ложных варнингов будет резко меньше, но при этом борроу-чекер будет пропускать некоторые случаи, на которые следовало бы ругнуться. И не факт, что в другом языке удастся создать способы преодоления этих варнингов, которые будут лучше чем костыль unsafe: в расте есть такие способы, но они требуют параметризации по типам, трейтов, функциональщины, системы модулей, и целой библиотеки, заточенной на всё это.

Ответить | Правка | К родителю #419 | Наверх | Cообщить модератору

442. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Аноним (442), 26-Май-20, 17:37 
Это вот так чтоли?

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Компилируется...

Ответить | Правка | Наверх | Cообщить модератору

446. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 26-Май-20, 18:24 
> Это вот так чтоли?
> https://play.rust-lang.org/?version=stable&mode=debug&editio...
> Компилируется...

Потому что в этом случае борроу-чекер справляется. Он в состоянии проанализировать код, и придти к выводу, что ref_a и ref_b ссылаются на непересекающиеся куски памяти.

Если код сделать чуть сложнее он споткнётся:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Может со временем борроу-чекер станет умнее и научится справляться и с этой ситуацией. Но прикинь теперь, что get_node принимает не идентификатор нода, а лямбду, и работает как std::iter::Iterator::find. И внутри лямбды я вызываю функцию находящуюся в другом крейте, которая вообще (с точки зрения компилятора) хрен знает что делает. Я применяю такой get_node дважды, и получаю две ссылки внутрь структуры. Борроу-чекер вообще уже никак не может проверить, что ref_a и ref_b ссылаются на непересекающиеся куски памяти. На самом деле это и мне может быть неочевидно в каких-то случаях, и мне отдельно придётся размышлять над этим.

Ответить | Правка | Наверх | Cообщить модератору

448. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Аноним (442), 26-Май-20, 18:40 
> Может со временем борроу-чекер станет умнее и научится справляться и с этой
> ситуацией. Но прикинь теперь, что get_node принимает не идентификатор нода, а
> лямбду, и работает как std::iter::Iterator::find. И внутри лямбды я вызываю функцию
> находящуюся в другом крейте, которая вообще (с точки зрения компилятора) хрен
> знает что делает. Я применяю такой get_node дважды, и получаю две
> ссылки внутрь структуры. Борроу-чекер вообще уже никак не может проверить, что
> ref_a и ref_b ссылаются на непересекающиеся куски памяти. На самом деле
> это и мне может быть неочевидно в каких-то случаях, и мне
> отдельно придётся размышлять над этим.

Конечно можно щас это всё на глупый borrow checker списать, но как до вызова некой неведомой какой лямбды можно было бы понять что она заимствовать будет? Здесь не проверятор тупой, а разработчик хочет невозможного.

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

Ответить | Правка | Наверх | Cообщить модератору

451. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 26-Май-20, 19:07 
> Конечно можно щас это всё на глупый borrow checker списать, но как
> до вызова некой неведомой какой лямбды можно было бы понять что
> она заимствовать будет? Здесь не проверятор тупой, а разработчик хочет невозможного.

Это не всегда "невозможное". Бывают случаи, когда я могу доказать, что создание двух ссылок не нарушит никаких инвариантов, а борроу-чекер не может доказать. И это же самый гнусный вариант: если я заткну борроу-чекер unsafe'ом, то потом изменения в программе могут привести к тому, что моё доказательство станет неверным, и я могу забыть проверить это доказательство. А если я буду разруливать по правилам борроу-чекера, то мне придётся переходить к динамическим проверкам borrow, что тоже сакс: мало того, что это дополнительные тормоза, так ещё и падения программы, происходящие при определённом стечении обстоятельств.

Но так или иначе, мне кажется, мы сходимся к одному и тому же: несмотря на прогресс в статическом анализе кода, пока ещё есть пределы возможностей всех этих статических проверок, есть куда улучшаться, и rust позволяет эти пределы пощупать.

Ответить | Правка | Наверх | Cообщить модератору

453. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от Аноним (442), 26-Май-20, 19:42 
> Это не всегда "невозможное". Бывают случаи, когда я могу доказать, что создание
> двух ссылок не нарушит никаких инвариантов, а борроу-чекер не может доказать.
> И это же самый гнусный вариант: если я заткну борроу-чекер unsafe'ом,
> то потом изменения в программе могут привести к тому, что моё
> доказательство станет неверным, и я могу забыть проверить это доказательство. А
> если я буду разруливать по правилам борроу-чекера, то мне придётся переходить
> к динамическим проверкам borrow, что тоже сакс: мало того, что это
> дополнительные тормоза, так ещё и падения программы, происходящие при определённом стечении
> обстоятельств.

Ты конкретного примера пока не привел. Ладно, давай я попробую что-то очевидное.
Для любого положительного целого i, ссылка на диапазон в массиве вида [0..(i/2)] очевидно не будет пересекаться с ссылкой вида [(i/2)..].
Почему бы это не проверять в borrow checker? Ну хотя бы для всех случаев, когда множество из одно range не пересекается с другим?

Ответить | Правка | Наверх | Cообщить модератору

456. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 26-Май-20, 19:56 
> Ты конкретного примера пока не привел.

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

> Для любого положительного целого i, ссылка на диапазон в массиве вида [0..(i/2)]
> очевидно не будет пересекаться с ссылкой вида [(i/2)..].
> Почему бы это не проверять в borrow checker? Ну хотя бы для
> всех случаев, когда множество из одно range не пересекается с другим?

И почему же? Для этого в slice есть split_at_mut, потому как борроу-чекер не умеет так, но я не задумывался, почему он этого не умеет, и почему бы его не научить этому.

Ответить | Правка | Наверх | Cообщить модератору

444. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от red75prim (?), 26-Май-20, 18:08 
> Я хочу получить N нодов [...], после чего провернуть какие-то манипуляции над ними, которые изменят все эти N нодов.

И проблема тут в том, что эти N указателей могут алиаситься. Делаем *node[0]=1; *node[1]=2; и получаем, что неожиданно *node[0] теперь тоже 2, так они указываются на один и тот же инт.

Если разные ноды принадлежат разным частям структуры (то есть алиасинг исключён), раст позволит это сделать:

struct Foo { a: Vec<i32>, b: Vec<i32> }

fn nodes(a: &mut Foo) -> Vec<&mut i32> {
    vec![&mut a.a[0], &mut a.b[0]]
}

Если алиасинг действительно нужен, то используется не i32, а Cell<i32> - zero-cost обёртка над i32 говорящая компилятору, что нам действительно нужен мутабельный алиасинг. Потом используем шареные ссылки на Cell<i32> и меняем данные через них. Борроу-чекер доволен.

Ответить | Правка | К родителю #433 | Наверх | Cообщить модератору

447. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Аноним (442), 26-Май-20, 18:29 
> Если алиасинг действительно нужен, то используется не i32, а Cell<i32> - zero-cost
> обёртка над i32 говорящая компилятору, что нам действительно нужен мутабельный алиасинг.
> Потом используем шареные ссылки на Cell<i32> и меняем данные через них.
> Борроу-чекер доволен.

...
И ловим косяки (если будут) в рантайме.

Ответить | Правка | Наверх | Cообщить модератору

449. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от red75prim (?), 26-Май-20, 18:52 
Дык, что написали, то и получим. Хотели мутабельный алиасинг, получили мутабельный алиасинг. Паник в коде с Cell<i32> не будет, могут быть логические ошибки.

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

Ответить | Правка | Наверх | Cообщить модератору

450. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 26-Май-20, 18:59 
Я понимаю в чём проблема, и я не говорю, что нельзя выкрутится в этой ситуации. Я говорю, что придётся городить огород мозголомных API.

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

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

> Cell<i32> - zero-cost обёртка над i32

Она лишь условно zero-cost. Она zero-cost в том смысле, что не надо заморочного рантайма, и что она добавляет O(1) сложности. Но это не значит, что она обходится бесплатно. Если ты попробуешь сделать для одного и того же RefCell<T> два borrow, то получишь панику: RefCell при создании ссылки проверяет не существует ли ещё одной. Точнее два borrow прокатят, но если один из них будет borrow_mut, то вот тогда ты получишь панику.

Кроме того, все эти Option<Arc<RefCell<SomeThing>>> иногда начинают напрягать. Особенно когда это накладывается на Result<Result<T, E1>, E2>.

> Если разные ноды принадлежат разным частям структуры (то есть алиасинг исключён), раст позволит это сделать:

Сможет, если он сможет проверить, что они принадлежат разным частям структуры. Выше, в #446, я привёл пример, где борроу-чекер самым тупым образом не справляется. Всё что потребовалось, для того, чтобы получить этот результат -- вынести создание ссылки в функцию. Проблема в том, что приходится сталкиваться с ситуациями, когда я могу доказать, что они всегда будут принадлежать разным частям структуры, а борроу-чекер -- нет. И из-за этого мне приходится либо доставать unsafe, либо скатываться на позорные динамические проверки. Причём, поскольку unsafe отменяет проверки, это значит что когда потом я внесу изменение в какой-нибудь другой код, и так случится что станет возможным создание двух ссылок на один и тот же кусок кода, то борроу-чекер нихрена не проверит, и динамической проверки нет, то есть я тупо впорюсь в баг, достойный C-программиста.

У всех этих проверок есть пределы возможностей, и эти пределы иногда реально путаются под ногами.

Ответить | Правка | К родителю #444 | Наверх | Cообщить модератору

452. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от red75prim (?), 26-Май-20, 19:22 
Cell именно что zero-cost.

> борроу-чекер самым тупым образом не справляется

Не тупым. Информацию о том, что структура позаимствована частично нужно где-то хранить. Хранить в рантайме дорого, значит нужно хранить в типе возвращаемого значения. Что именно заимствуется зависит от входных параметром, значит выходный тип должен зависеть от входного значения. А это уже dependent types и намного сложнее.

Ответить | Правка | Наверх | Cообщить модератору

455. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 26-Май-20, 19:51 
> Cell именно что zero-cost.
>> борроу-чекер самым тупым образом не справляется
> Не тупым. Информацию о том, что структура позаимствована частично нужно где-то хранить.
> Хранить в рантайме дорого, значит нужно хранить в типе возвращаемого значения.
> Что именно заимствуется зависит от входных параметром, значит выходный тип должен
> зависеть от входного значения. А это уже dependent types и намного
> сложнее.

Именно что тупым. Мне не требуется более сложной системы типов в расте, для того, чтобы рассуждать лучше борроу-чекера о данной ситуации. И борроу-чекеру dependent types особо не нужны -- он же может в пределах одной функции придти к выводу, что создаётся две независимые ссылки внутрь структуры? И может он это сделать без dependent types. Его тупость проявляется в том, что его способность рассуждать не может пересекать границ функций.

Ответить | Правка | Наверх | Cообщить модератору

457. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от red75prim (?), 26-Май-20, 20:15 
Это будет не рассуждение, а "натыкать вариантов для частных случаев". Линейный конгруэнтный метод генерации случайных чисел, может выводить уникальные индексы из какого-то диапазона пока не начнёт повторяться. Использовать N этих индексов будет безопасно, ссылки не будут пересекаться. Этот случай тоже добавлять в borrow checker?

Доказать отсутствие алиасинга в общем случае невозможно. Тривиальные случаи решаются тривиально: например не использовать отдельную функцию get_node, чтобы borrow-checker видел, что берутся разные элементы. Нетривиальные случаи доказываются вручную и изолируются за безопасным интерфейсом.

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

Ответить | Правка | Наверх | Cообщить модератору

169. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +2 +/–
Сообщение от Зз (?), 24-Май-20, 20:11 
А как это будет на Расте?
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

257. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –2 +/–
Сообщение от растоман (?), 24-Май-20, 22:16 
> А как это будет на Расте?

unsafe {
тажехерня
}

Ответить | Правка | Наверх | Cообщить модератору

274. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –4 +/–
Сообщение от Аноним (222), 24-Май-20, 23:01 
Истину глаголит
Ответить | Правка | Наверх | Cообщить модератору

285. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от JL2001 (ok), 24-Май-20, 23:09 
>> А как это будет на Расте?
> unsafe {
> тажехерня
> }

https://www.opennet.ru/openforum/vsluhforumID3/120718.html#283

Ответить | Правка | К родителю #257 | Наверх | Cообщить модератору

342. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –3 +/–
Сообщение от Аноним (340), 25-Май-20, 08:12 
unsafe{
    main(){
    ///весь остальной код
    }
}
Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

383. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +1 +/–
Сообщение от Ordu (ok), 25-Май-20, 12:40 
Раст не позволит хранить ссылку в двух разных местах просто так. Там без явного или неявного использования unsafe не удастся выкрутится. Например, в std есть Rc, который может приделать к объекту счётчик ссылок, и при помощи unsafe он может клонировать и удалять ссылки таким образом, чтобы после удаления последней, вызвать free на объект. Если использовать Rc, то тебе самому не надо прибегать к помощи unsafe (всё это спрятано в Rc, наружу Rc выставляет safe интерфейс).

В C++ есть shared_ptr, который делает то же самое. Разница лишь в том, что C++ с радостью позволит тебе сделать всё то же самое без shared_ptr, и получить use-after-free, в то время как rust заставит тебя обратить внимание на сложившуюся ситуацию и совершить какие-то телодвижения.

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

341. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от Аноним (340), 25-Май-20, 08:11 
Объект замыкание должно отвалиться с исключением или игнорированием события, в зависимости от контекста.
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

358. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  –1 +/–
Сообщение от Аноним (358), 25-Май-20, 10:07 
Там должен быть не указатель, а shared_ptr. И тогда в описанной ситуации обработчик обратится к объекту отключенному от дерева и у которого parent == null. Правда тут мы получим классическую утечку памяти. В идеале менеджер сообщений должен отработать только после изменения и пересчёта DOM.
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

368. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от Lex (??), 25-Май-20, 10:53 
В подобных случаях( правда, на уровне того же веба и жс ) обычно на удаление вешают функцию, которая вначале очищает все обработчики событий( всм, относящиеся к конкретному объекту ) и, уже только после этого, выпиливается сам объект( мб, даже по какому-нибудь колбэку аля onDone / onSuccess, притом, с проверкой актуальности самой ссылки на удаляемый объект, т.к в вебе может и несколько запросов на удаление прилететь.. что-то где заглючило или браузер лаганул и в этот момент юзер кучу раз нажал на соотв кнопку итп )
Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

418. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от Андрей (??), 26-Май-20, 03:14 
> например, это может быть замыкание, которое захватило указатель на кусок памяти представляющий эту кнопку.

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

Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

429. "70% проблем с безопасностью в Chromium вызваны ошибками при ..."  +/–
Сообщение от Ordu (ok), 26-Май-20, 13:39 
>> например, это может быть замыкание, которое захватило указатель на кусок памяти представляющий эту кнопку.
> Похоже, если нужно захватывать указатель, то нужно захватывать указатель на этот указатель.
> Если уж добвалять синтаксический сахар, так не оставлять при этом дыр.

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

Есть другие способы. Во-первых, сборка мусора в том или ином виде -- счётчики ссылок или сборщик мусора. Во-вторых, можно очень подумать головой, и придумать такие структуры данных и такие алгоритмы работы с ними, чтобы ничего подобного не случалось. "Во-первых" -- это обобщённое решение для всех таких проблем, "во-вторых" -- это "ad hoc" решение, которое затачивается под конкретный случай.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру