The OpenNET Project / Index page

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



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

Оглавление

Локальная root-уязвимость в подсистеме inotify ядра Linux, opennews (??), 04-Авг-17, (0) [смотреть все]

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


11. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +/
Сообщение от Аноним (-), 04-Авг-17, 23:43 
Давай, расскажи нам, какие языки позволяют избежать гонки.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

17. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +2 +/
Сообщение от анонимус (??), 05-Авг-17, 00:15 
хаскель с STM
Ответить | Правка | Наверх | Cообщить модератору

21. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +5 +/
Сообщение от irinat (ok), 05-Авг-17, 00:54 
Как ни странно, Rust. Концепция владения и заимствования нацелена на разделение ресурсов и предотвращение гонок. Но если хочется, всегда есть unsafe.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

26. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +3 +/
Сообщение от angra (ok), 05-Авг-17, 03:36 
Правильнее было бы сказать, что Rust позволяет предотвратить больше вариантов race condition, чем C. Но защитить от вобще всех вариантов race condition он само собой не может.
Ответить | Правка | Наверх | Cообщить модератору

51. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +/
Сообщение от Crazy Alex (ok), 05-Авг-17, 15:33 
По идее он только от чего-то совсем тривиального сможет защитить - ценой довольно основательных неудобств для программиста. Стоит ли оно того - лет через пять-семь увидим...
Ответить | Правка | Наверх | Cообщить модератору

61. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +/
Сообщение от irinat (ok), 05-Авг-17, 18:40 
Просто не нужно писать Си-код на Rust. Так-то программисты могут писать фортран-программы на любом языке программирования. Просто так делать не стоит.
Ответить | Правка | Наверх | Cообщить модератору

64. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +/
Сообщение от Аномномномнимус (?), 05-Авг-17, 19:58 
yet another "просто не нужно писать код, если он не идеальный", только со своей колокольней, куликами и болотом, ага
Ответить | Правка | Наверх | Cообщить модератору

48. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +/
Сообщение от Crazy Alex (ok), 05-Авг-17, 12:27 
Те, которые многопоточность толкмо не могут, конечно. В остальных - в крайнем случае для гонки понадобится ошибка в реализации среды. Чудес не бывает.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

98. "Локальная root-уязвимость в подсистеме inotify ядра Linux"  +/
Сообщение от Очередной аноним (?), 18-Авг-17, 11:26 
> Давай, расскажи нам, какие языки позволяют избежать гонки.

Тот же D. Все "обычные" переменные локальны для потоков. Т.е. если ты объявишь "int a;" то в D это будет не глобальная переменная, которую может крутить каждый поток, конкурируя с соперниками. В D каждый поток получит свою копию этой переменной, которая будет храниться в TLS (thread-local storage). Если же тебе кровь из носу понадобится разделять её между потоками, то ты ее объявляешь разделяемой - "shared int a;". И компилятор теперь знает, что она разделяется между потоками и запретит тебе совершать над ней опасные, не синхронизированные, действия. Т.е. ты не сможешь тупо сделать "++a;", компилятор ругнется. Для этого  тебе придется использовать специальные атомарные примитивы из модуля std.concurrency для исключения одновременного незащищенного доступа. И вообще, там (в D) для взаимодействия потоков побуждают использовать подсистему сообщений, максимально локализуя, обособляя потоки друг от друга. Взаимодействие через разделяемые данные (которые с квалификатором shared и конечно с помощью мьютексов и прочего из std.concurrency)  оправданно только если объемы этих данных большие и копирование их в виде сообщений накладно.

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

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

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




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

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