https://www.opennet.me/openforum/vsluhforumID3/111914.html Группа исследователей из Китайского университета Гонконга выявила (http://openwall.com/lists/oss-security/2017/08/03/2) уязвимость <br>(CVE-2017-7533 (https://security-tracker.debian.org/tracker/CVE-2017-7533)) в ядре Linux, которая может использоваться для повышения своих привилегий в системе. Проблема проявляется начиная с ядра v3.14-rc1 и актуальна вплоть до ядра 4.12. В сети уже распространяется эксплоит для 32-разрядых систем. Для 64-разрядных систем эксплоит пока отсутствует, но теоретически нет преград для его создания.<br><br><br><br><br>Уязвимость вызвана состоянием гонки между обработкой события inotify и вызовом vfs_rename() в VFS, возникающим при выполнении операции переименования над тем же файлом. Атакующий может добиться ситуации, при которой после обработки события inotify указатель указывает на новое имя файла, а буфер выделен для старого имени. Соответственно хвост нового имени файла сохраняется за пределами буфера и переписывает данные за границей текущего slab (https://ru.wikipedia.org/wiki/Slab), нап https://www.opennet.me/openforum/vsluhforumID3/111914.html#98 Fri, 18 Aug 2017 08:26:06 GMT &gt; Давай, расскажи нам, какие языки позволяют избежать гонки.<br><br>Тот же D. Все "обычные" переменные локальны для потоков. Т.е. если ты объявишь "int a;" то в D это будет не глобальная переменная, которую может крутить каждый поток, конкурируя с соперниками. В D каждый поток получит свою копию этой переменной, которая будет храниться в TLS (thread-local storage). Если же тебе кровь из носу понадобится разделять её между потоками, то ты ее объявляешь разделяемой - "shared int a;". И компилятор теперь знает, что она разделяется между потоками и запретит тебе совершать над ней опасные, не синхронизированные, действия. Т.е. ты не сможешь тупо сделать "++a;", компилятор ругнется. Для этого тебе придется использовать специальные атомарные примитивы из модуля std.concurrency для исключения одновременного незащищенного доступа. И вообще, там (в D) для взаимодействия потоков побуждают использовать подсистему сообщений, максимально локализуя, обособляя потоки друг от друга. Взаимодействие через разделяемые данные (которы https://www.opennet.me/openforum/vsluhforumID3/111914.html#97 Tue, 15 Aug 2017 16:29:39 GMT &gt;[оверквотинг удален]<br>&gt;&gt; сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, <br>&gt;&gt; а второй поток начинает читать от туда, но первый ещё не <br>&gt;&gt; досохранял. Такое вот rust никак не отследит.<br>&gt;&gt; А то что у вас, это просто переменная в памяти, которая в <br>&gt;&gt; двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, <br>&gt;&gt; случайно где-нибудь наступить можно.<br>&gt; При всём при этом, возникает вопрос, придется ли мучится, если реально логикой <br>&gt; эти потоки разделены, то есть одновременное выполнение кода не возможно, потому <br>&gt; что второй поток уснул в ожидание. Я так понял, rust за <br>&gt; такое будет пинать <br><br>На такие случаи есть RefCell. RefCell сам по себе immutable объект (а значит можно одновременно иметь много ссылок на него), но если его попросить, то он выдаст mutable ссылку на содержащийся в нём объект. При этом он выполнит в рантайме проверки того, что в любой момент времени существует только одна mutable ссылка на объект. По сути, этот RefCell -- это те же проверки, которые https://www.opennet.me/openforum/vsluhforumID3/111914.html#96 Tue, 15 Aug 2017 16:24:25 GMT &gt; Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, <br>&gt; сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, <br>&gt; а второй поток начинает читать от туда, но первый ещё не <br>&gt; досохранял. Такое вот rust никак не отследит.<br><br>Чем эта гонка "логическая"? Чтобы читать в или писать из File нужна mutable ссылка на этот File. Но rust запрещает иметь две mutable ссылки. В зависимости от того, каким образом вы попытаетесь создать две такие ссылки в разных потоках, вы получите либо ошибку компиляции, либо падение одного из потока в панику в описываемой ситуации, либо блокирование одного потока до завершения операции в другом.<br><br>Другое дело, что потоки могут независимо придти к выводу, что файл надо открыть и что-то с ним сделать, и у них будет два разных объекта File. И да, от этого rust не защитит. Но в этом случае, race происходит _вне_ rust'а. Здесь же речь идёт о _memory_ safety.<br><br>&gt; А то что у вас, это просто переменная в памяти, которая в <br>&gt; двух потоках трогае https://www.opennet.me/openforum/vsluhforumID3/111914.html#95 Tue, 15 Aug 2017 09:35:16 GMT &gt; Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, <br>&gt; сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, <br>&gt; а второй поток начинает читать от туда, но первый ещё не <br>&gt; досохранял. Такое вот rust никак не отследит.<br>&gt; А то что у вас, это просто переменная в памяти, которая в <br>&gt; двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, <br>&gt; случайно где-нибудь наступить можно.<br><br>При всём при этом, возникает вопрос, придется ли мучится, если реально логикой эти потоки разделены, то есть одновременное выполнение кода не возможно, потому что второй поток уснул в ожидание. Я так понял, rust за такое будет пинать<br> https://www.opennet.me/openforum/vsluhforumID3/111914.html#94 Tue, 15 Aug 2017 09:33:35 GMT Это все простейшие примеры. А логические гонки, когда, например (первое что пришло, сильно надуманно, но думаю степень можно опять), мы сохраняем на диск, а второй поток начинает читать от туда, но первый ещё не досохранял. Такое вот rust никак не отследит.<br><br>А то что у вас, это просто переменная в памяти, которая в двух потоках трогается. Такое "ещё в школе проходят", хотя не спорю, случайно где-нибудь наступить можно.<br> https://www.opennet.me/openforum/vsluhforumID3/111914.html#93 Sun, 13 Aug 2017 15:48:25 GMT &gt; Енжой ёр Си.<br><br>А что, есть ЯП где гонки невозможно сделать принципиально?<br> https://www.opennet.me/openforum/vsluhforumID3/111914.html#92 Fri, 11 Aug 2017 16:46:02 GMT &gt; Тут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие Rust/Go/D ?<br><br>Не совсем так. Выгодно всем, кто хоть немного в теме. Вопрос в том, кто вкладывается.<br><br>&gt; Приведу пример: MS Visual Studio принципиально не поддерживает стандарт C11 до сих <br>&gt; пор.<br><br>А майкрософтовский C++ компилятор ещё жив? Ну, в смысле, есть gcc, есть llvm, зачем кому-нибудь может быть нужен майкрософтовский компилятор? Если нужен MSVS, то проще ведь воткнуть llvm в MSVS и не париться на этот счёт больше никогда. То есть, я не в курсе на самом деле, писать какой-либо код под венду я не пытался очень давно и очень давно не интересовался как это надо делать. Может быть там все давно перешли писать на паскале, а я и не заметил.<br><br>Вообще же это майкрософт в её стиле. Если MS занимается поддержкой какой-нибудь не своей технологии, то исключительно с целью перетянуть одеяло на себя. С C++ им особо ничего не светит в их понимании света. Поэтому они не будут заморачиваться поддерживать какие-то там стандарты C++. MS нико https://www.opennet.me/openforum/vsluhforumID3/111914.html#91 Fri, 11 Aug 2017 14:20:34 GMT &gt; считать что индукция в данном случае -- неверный способ рассуждений<br><br>Тут верный способ рассуждений такой: а кому ВЫГОДНО вкладываться в развитие Rust/Go/D ?<br><br>Приведу пример: MS Visual Studio принципиально не поддерживает стандарт C11 до сих пор.<br> https://www.opennet.me/openforum/vsluhforumID3/111914.html#89 Tue, 08 Aug 2017 18:31:28 GMT &gt; Почему перебегать улицу на красный свет плохо, мне объясняли.<br><br>Для будущего асфальторовнятеля в модной оранжевой робе этого достаточно.<br>