forum.opennet.ru - "Уязвимость в механизме ucount ядра Linux, позволяющая повысить свои привилегии" (102)

"Уязвимость в механизме ucount ядра Linux, позволяющая повысить свои привилегии"

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

"Уязвимость в механизме ucount ядра Linux, позволяющая повысить свои привилегии"	+/–
Сообщение от opennews (??), 31-Янв-22, 12:06
В ядре Linux в коде обработки ограничений rlimit в разных пространствах имён идентификаторов пользователей (user namespaces) выявлена уязвимость (CVE-2022-24122), позволяющая повысить свои привилегии в системе. Проблема проявляется начиная с ядра Linux 5.14 и будет устранена в обновлениях 5.16.5 и 5.15.19. Стабильные ветки Debian, Ubuntu, SUSE/openSUSE и RHEL проблема не затрагивает, но проявляется в свежих ядрах Fedora и Arch Linux... Подробнее: https://www.opennet.me/opennews/art.shtml?num=56610
Ответить \| Правка \| Cообщить модератору

Оглавление

Ну что, кто-нибудь ещё скажет что-нибудь после такого о превосходстве Сишников , Аноним (1), 12:06 , 31-Янв-22, (1) –8

Я тебя даже плюсанул Вполне неплохой наброс , Урри (ok), 12:08 , 31-Янв-22, (3) +11

Такой неплохой наброс можно писать под каждой новостью про очередную сишную дыру, Аноним (26), 12:58 , 31-Янв-22, (26) +9

И это хорошо Приятно начинать день с чашечки вкусного кофе и приятных набросов н, Урри (ok), 13:29 , 31-Янв-22, (38) +4

С мыслью этому миру нужно больше дыр , Аноним (26), 13:32 , 31-Янв-22, (41) +7

До слёз , Аноним (46), 14:03 , 31-Янв-22, (46)
Говори за себя, дыра , malloc (?), 20:05 , 31-Янв-22, (95)

Головка , Аноним (14), 12:34 , 31-Янв-22, (14) –5

Вертеть , DD (??), 14:59 , 31-Янв-22, (57)

Безопасный язык только предотвращает ситуации, от которых всё падает Это значи, Аноним (90), 18:30 , 31-Янв-22, (90) –1

Это значит что и у Си после вычесывания удачи типичных ошибок переполнениями , Аноним (104), 10:21 , 01-Фев-22, (104) +2

Ну вот Видишь И зачем тогда нужен этот ваш Раст пошел выкручивать из машин, Аноним (-), 17:34 , 01-Фев-22, (106) –1

так ведь при желании Если есть желание самоубиться - пжалста Но только наС, Аноним (104), 17:57 , 01-Фев-22, (107)

Для сишечки тоже есть умные указатели Например, https github com Snaipe libcsp, Урри (ok), 12:08 , 31-Янв-22, (2) +1

Умные указатели для неумных людей , Аноним (6), 12:11 , 31-Янв-22, (6) –1

Умные люди, видимо, получают use-after-free уязвимости, ilyafedin (ok), 12:21 , 31-Янв-22, (12) +17

На раст уже редох написали Ага, дайте две , Аноним (81), 17:33 , 31-Янв-22, (81) –1

Ну это опционально, а нужно чтобы принудительно было, чтобы нельзя было забыть ч, Аноним (1), 12:12 , 31-Янв-22, (7)

Не компиляторного А со стороны непрерывной интеграции , Урри (ok), 13:31 , 31-Янв-22, (39)

Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыл, Аноним (1), 14:59 , 31-Янв-22, (56)

Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловор, Урри (ok), 15:14 , 31-Янв-22, (59) –5

Да понятно дело, но ведь это обусловлено несовершенствами наших языковПо содержа, Аноним (1), 15:24 , 31-Янв-22, (62) +1

Берите шире - Вселенной И это не стеб и не сарказм Если при этом не ломать рабо, Урри (ok), 16:08 , 31-Янв-22, (67) –1

Почему Абстрактные рассуждения про цену звучат, конечно, классно, но где конкрет, Аноним (69), 16:37 , 31-Янв-22, (69)

Узковато мыслите Добавьте сюда цена разработки и цена сопровождения , Урри (ok), 17:29 , 31-Янв-22, (79) –2

Так снижается же цена сопровождения наоборот, по сравнению с опасной процедурой, Аноним (69), 18:00 , 31-Янв-22, (83)

Цена чего Покажи пример большого оверхеда Ты можешь завернуть критический участ, Анонн (?), 17:23 , 31-Янв-22, (73) +1

Разработки и сопровождения у вас, растоманов, совсем каша в голове Я так и не п, Урри (ok), 17:53 , 31-Янв-22, (82) –1

Ниже Ordu писал о проблеме - проблема в семантике Си, в которой очень многое, с , Аноним (69), 18:06 , 31-Янв-22, (86) +1
Ну и где примеры высокой цены Разработки и сопровождения на расте То что научи, Анонн (?), 18:21 , 31-Янв-22, (87) –1
- code 1 2 The Structure of a Compiler1 2 1 Lexical Analysis1 2 2 Syntax Analysi, Аноним (-), 20:44 , 31-Янв-22, (99) +1

Когда закончились аргументы, побежим размахивать авторитетами Слив засчитан, м, Урри (ok), 00:22 , 01-Фев-22, (100) –3

Когда Урри опять с умным видом пyкнул в лужу, демонстрируя незнание азов и _обще, Аноним (-), 03:31 , 01-Фев-22, (102)

не обязательно логика простая - чем раньше обнаружена ошибка, тем ее дешевле пр, анонимус (??), 16:22 , 31-Янв-22, (68)

Не спорю, но чем больше у нас проверок на ранних этапах, тем лучше Надеяться то, Аноним (69), 16:38 , 31-Янв-22, (70) +1

ну нафиг, если они такие умные то рано или поздно выйдут из под контроля и образ, Аноним (8), 12:13 , 31-Янв-22, (8) +2

Ты чё, умный дох я А, указатель Память есть А если найду , Жироватт (ok), 12:17 , 31-Янв-22, (11)

память как бы не его, он на неё показать токмо и может, Аноним (8), 13:00 , 31-Янв-22, (28)

Ну это с какой стороны посмотреть Умные указатели еще и для того чтобы память н, bOOster (ok), 13:06 , 31-Янв-22, (30)

Там же только uniq_ptr и shared_ptr, причём со всеми граблями C овых аналогов,, Ordu (ok), 14:07 , 31-Янв-22, (47) +13

Как поставить 100 плюсов , Аноним (51), 14:44 , 31-Янв-22, (51) +7
Браво за детальный ответ, сударь , Аноним (1), 15:08 , 31-Янв-22, (58)
А ещё C абстракции не бесплатны Например инициализация памяти с помощью констр, Аноним (46), 17:28 , 31-Янв-22, (77)
Но я как бы и не говорил что умные указатели - серебряная пуля Любой задаче, са, Урри (ok), 18:01 , 31-Янв-22, (84) +1

Зато ты постоянно говорил, что умные указатели в плюсах - это так же эффективно , Прохожий (??), 02:55 , 03-Фев-22, (111) –1

Да И продолжаю это говорить А сообщество в каждой новости это подтверждает А ве, Урри (ok), 12:50 , 14-Фев-22, (116)

Не забывай в зеркало почаще смотреться Ты гораздо хуже Я-то прекрасно понял Та, Прохожий (??), 01:47 , 16-Фев-22, (118)

Ладно крах при разименовывании NULL Но от что позволяло добиться выполнения св, Аноним (88), 18:26 , 31-Янв-22, (88)

А толку что есть Их все равно никогда при жизни Линукса, по крайней мере не з, Анонн (?), 14:15 , 31-Янв-22, (50)

Сишники, вообще-то, знают когда автоматическое управление памятью хорошо, а когд, Урри (ok), 18:03 , 31-Янв-22, (85) –2

Q Can I use this on a serious project A Yes, but as this project has not been, Прохожий (??), 01:48 , 03-Фев-22, (110)

Скрыто модератором, Урри (ok), 12:52 , 14-Фев-22, (117)

Второй ebpf, макпыф (ok), 12:08 , 31-Янв-22, (4)

отключается в отличие от, как я понял проблема в очередной раз притянута за уши , Аноним (10), 12:15 , 31-Янв-22, (10) +1

всм оба отключаются Я про решетo, половина уязвимостей в ядре - ebpf и usernsP, макпыф (ok), 12:33 , 31-Янв-22, (13) –1

как отключить ebpf в актуальном ядре , Аноним (10), 12:49 , 31-Янв-22, (21) +1

CONFIG_BPF_SYSCALL is not set CONFIG_BPF_JIT is not setCONFIG_BPF как я понял, макпыф (ok), 12:52 , 31-Янв-22, (22)

Это не ebpf В выводе видно на что он влияет, но он тоже не отключается большеCO, Аноним (10), 12:55 , 31-Янв-22, (24)

cbpf мертв, не помню удалили его полностью или нет, но всегда используется ebpfИ, макпыф (ok), 13:00 , 31-Янв-22, (27)

Раньше можно было убрать любые упоминания , Аноним (10), 13:17 , 31-Янв-22, (34)

Нафига Удобная же штука Можно создавать правила фильтрации айпишников на контр, Аноним (26), 13:31 , 31-Янв-22, (40) +1

Ну не всем и не всегда это требуетсяВ принципе, в 5 16 так и сделано по дефолту, макпыф (ok), 20:27 , 31-Янв-22, (96)

Если бы вы увидели список всего, на что агриться это чудо, то вы бы истерично см, Аноним (65), 15:57 , 31-Янв-22, (65)

Всего-то на всего Тьфу ерунда , Аноньимъ (ok), 12:38 , 31-Янв-22, (16)

Если бы кое-кто выполнял работу более аккуратно, этого можно было бы избежать И, Аноним (10), 12:54 , 31-Янв-22, (23)

первый Лет десять уже этой попытке сделать чтоб вот любой юзер был как рут, но н, Аноним (35), 13:18 , 31-Янв-22, (35)
Первый хронологически , псевдонимус (?), 15:23 , 31-Янв-22, (61)

sysctl cannot stat proc sys kernel unprivileged_userns_clone No such file or , Аноним (10), 12:10 , 31-Янв-22, (5) –1
Уязвимость в механизме ucount ядра Linux, позволяющая повыси..., Аноним (6), 12:13 , 31-Янв-22, (9) –5

Наконец-то настоящий эксперт опеннета Пользуется неподдерживаемым ядром без еди, НяшМяш (ok), 13:40 , 31-Янв-22, (43) +3

Актуальные бунту ядра поддерживаются самой канониклой, а вот насколько эта сикур, Аноним (65), 16:01 , 31-Янв-22, (66) +3

Меня смущает тот факт, что патч версия у Анонима 6 до сих пор 0, хотя на керне, НяшМяш (ok), 19:17 , 31-Янв-22, (93) –1

У убунты ядро всегда версии x y 0, они много чего в него переносят, не поднимая , mikhailnov (ok), 20:01 , 31-Янв-22, (94) –1

Вот и разбиваются доводы Военов АнтиРастового Сопротивления о суровую реальность, Аноним (46), 12:34 , 31-Янв-22, (15) –5
А вы спрашиваете, зачем стейбл во времена блидинг эджей , Аноним (17), 12:44 , 31-Янв-22, (17) –1
пикачу Wrust - я выбираю тебя , Шарп (ok), 12:44 , 31-Янв-22, (18) –2

А C уже всё, не в моде , Аноним (14), 13:10 , 31-Янв-22, (31) +3

Будето там такого нельзя При желании тоже можно звать объект после вызова дестр, Аноним (88), 18:29 , 31-Янв-22, (89)

А что не питон , Аноним (36), 13:20 , 31-Янв-22, (36) +1

Захохотал, Fracta1L (ok), 13:48 , 31-Янв-22, (45) –2

Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживае, Аноним (46), 14:08 , 31-Янв-22, (48)

Ядро тестируют на пользователях, это официальная позиция корпораций-разработчико, Аноним (55), 14:50 , 31-Янв-22, (55) –2
Для этого нужно прогнать через всевозможные сценарии использования и окружения , anonymous (??), 11:57 , 03-Фев-22, (112)

Да, я тоже посмеялся , Аноним (55), 14:48 , 31-Янв-22, (54) –1

Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала пр, Аноним (-), 16:43 , 31-Янв-22, (71)

Гениально, Карл С такими вводными не то чтобы use-after-free, я даже не знаю чт, самокатофил (?), 19:16 , 31-Янв-22, (92) –2

Если не знаете -- это понятно Но вы не увиливайте там use-after-free много уже, anonymous (??), 12:02 , 03-Фев-22, (113)

Rust-то такого не позволяет Он просто память не освобождает, потому и нет use-a, Аноним (14), 21:07 , 02-Фев-22, (109)

В смысле не освобождает Вы про что Можно так же ссылку на первоисточник И н, anonymous (??), 12:04 , 03-Фев-22, (114)

Йохохо, всего два дня прошло с предыдущей дыры, а тут уже новая подоспела И опя, Анонн (?), 14:11 , 31-Янв-22, (49) +2

Растовчане то так не могут, что за неудачники, Аниме (?), 14:46 , 31-Янв-22, (53)

Янукович Co , DD (??), 15:38 , 31-Янв-22, (64)

И снова неймспейсы Эта музыка будет вечной , псевдонимус (?), 15:16 , 31-Янв-22, (60) –1
И снова перекидывания фекалиями фанатиков раста и сишечки Дело не в том, что как, RAMbug (?), 15:32 , 31-Янв-22, (63) +5

И тут ты такой из-за угла с продуманной архитектурой Что, нету Странно , nvidiaamd (?), 20:31 , 31-Янв-22, (98) +1

Растаманьки, скажите, а правда что в расте невозможен use after free по определе, самокатофил (?), 16:50 , 31-Янв-22, (72) –1

у растенек все течёт, но это безопасно ведь порчи данных не будет, будет постоя, Аноним (-), 19:04 , 31-Янв-22, (91) –2

Да ладно, всё решается избыточностью - запускаем, допустим, пять контейнеров, в , x3who (?), 03:08 , 01-Фев-22, (101) +1

Скорее всего получится ситуация а вы друзья, как ни садитесь, всё в музыканты н, www2 (??), 07:50 , 14-Фев-22, (115)

Теперь будет Rust Kernel за место Linux Kernel xDDDDDDDD, soup2 (?), 08:32 , 01-Фев-22, (103)
что-то в винде меньше дырок чем находят в linux kernel , Аноним (105), 13:04 , 01-Фев-22, (105) –1

Вы не поверите - у винды исходники закрыты, поэтому приходится страдать и искать, Аноним (108), 00:46 , 02-Фев-22, (108)

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

1. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –8 +/–

Сообщение от Аноним (1), 31-Янв-22, 12:06

Ну что, кто-нибудь ещё скажет что-нибудь после такого о превосходстве Сишников? То-то же! Раст всем голова.

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

3. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +11 +/–

Сообщение от Урри (ok), 31-Янв-22, 12:08

Я тебя даже плюсанул. Вполне неплохой наброс.

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

26. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +9 +/–

Сообщение от Аноним (26), 31-Янв-22, 12:58

Такой неплохой наброс можно писать под каждой новостью про очередную сишную дыру. То есть минимум раз день.

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

38. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +4 +/–

Сообщение от Урри (ok), 31-Янв-22, 13:29

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

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

41. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +7 +/–

Сообщение от Аноним (26), 31-Янв-22, 13:32

С мыслью "этому миру нужно больше дыр".

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

46. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (46), 31-Янв-22, 14:03

До слёз ;)

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

95. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от malloc (?), 31-Янв-22, 20:05

Говори за себя, дыра.

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

14. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –5 +/–

Сообщение от Аноним (14), 31-Янв-22, 12:34

Головка.

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

57. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от DD (??), 31-Янв-22, 14:59

Вертеть?

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

90. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (90), 31-Янв-22, 18:30

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

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

104. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +2 +/–

Сообщение от Аноним (104), 01-Фев-22, 10:21

> Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код.
Это значит что и у Си после вычесывания (удачи!) типичных ошибок переполнениями и т.п. (которых 70%), допущенных наСильниками, останется 30% ошибок, "для выявления которых придётся больше думать и серъёзнее анализировать код". Только еще хуже - в типичной Си-шной многопоточке еще дополнительный ворох нетривиальных проблем подбрасывается (всякие рэйс-кондишоны), в отличие от типичной многопоточки Раста с его понятием владения, по дефолту взаимодействием посредством передачи сообщений и пр. (хотя на Расте тоже можно при желании в сишном стиле написать, с разделяемыми между потоками данными и объектами синхронизации и поиметь тот же ворох проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").

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

106. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (-), 01-Фев-22, 17:34

> (хотя на
> Расте тоже можно при желании в сишном стиле написать, с разделяемыми
> между потоками данными и объектами синхронизации и поиметь тот же ворох
> проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").
Ну вот! Видишь! И зачем тогда нужен этот ваш Раст? * пошел выкручивать из машины ненужные подушки и ремни безопасности вместе со смузихлебными ESC и ABS *

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

107. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (104), 01-Фев-22, 17:57

так ведь "при желании"! Если есть желание "самоубиться" - пжалста! Но только наСильник будет пытаться упорно применять техники из Си в Расте.

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

2. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Урри (ok), 31-Янв-22, 12:08

Для сишечки тоже есть умные указатели.
Например, https://github.com/Snaipe/libcsptr
Но в ядре их не используют.

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

6. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (6), 31-Янв-22, 12:11

Умные указатели для неумных людей.

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

12. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +17 +/–

Сообщение от ilyafedin (ok), 31-Янв-22, 12:21

Умные люди, видимо, получают use-after-free уязвимости

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

81. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (81), 31-Янв-22, 17:33

На раст уже редох написали. Ага, дайте две.

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

7. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (1), 31-Янв-22, 12:12

Ну это опционально, а нужно чтобы принудительно было, чтобы нельзя было забыть что-то где-то. Максимум компиляторногг контроля

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

39. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Урри (ok), 31-Янв-22, 13:31

Не компиляторного. А со стороны непрерывной интеграции.

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

56. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (1), 31-Янв-22, 14:59

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

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

59. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –5 +/–

Сообщение от Урри (ok), 31-Янв-22, 15:14

> Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль.
Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда.
Я бы вообще просто по фразе "CI - костыль" выпинывал из профессии назад в то ПТУ, где оного персонажа учили, на второй год.
> Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход
Это корректный код?
float sine(float x)
{
  return cos(x);
}
а это?
float enis(float x)
{
  return cos(x);
}
Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?

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

62. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (1), 31-Янв-22, 15:24

> Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда
Да понятно дело, но ведь это обусловлено несовершенствами наших языков
> Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?
По содержательным вещам - пишется спецификация и доказывается. Пример - seL4
Что же касается темы Си, Раста и всего такого - если можно вложить доп проверки, почему не вложить? Си пропустит такой кусок кода
int * x;
if <somecond> {
int tmp = 1;
x = &tmp;
}
хотя он явно не корректен и поймать это легко. Что Раст и делает и не допускает такой код

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

67. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Урри (ok), 31-Янв-22, 16:08

> Да понятно дело, но ведь это обусловлено несовершенствами наших языков
Берите шире - Вселенной. И это не стеб и не сарказм.
> если можно вложить доп проверки, почему не вложить?
Если при этом не ломать работающее, конечно же. Или вы так не думаете?
> Что Раст и делает и не допускает такой код
За цену этого "не допускает" не хотите поговорить? Ну то-есть как бы за все надо платить, не так ли? Или не важно?
Я вот, например, от такого кода очень легко избавлюсь с помощью специального инструментария, называемого статическими анализаторами. При этом у меня остается свобода написания высокоскоростного кода.
А у вас не остается.
Вот если я предложу ради безопасности вашего ребенка (машина не собьет, маньяк не зарежет) поместить его навечно в дурку - вы согласитесь? Я думаю - нет.
Вот и тут так же.

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

69. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (69), 31-Янв-22, 16:37

> При этом у меня остается свобода написания высокоскоростного кода.
> А у вас не остается.
Почему?
Абстрактные рассуждения про цену звучат, конечно, классно, но где конкретные примеры того, что Раст даёт сильную просадку по производительности именно из-за запрета того или иного кода?

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

79. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от Урри (ok), 31-Янв-22, 17:29

> где конкретные примеры того, что Раст даёт сильную просадку по производительности
Узковато мыслите. Добавьте сюда "цена разработки" и "цена сопровождения".

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

83. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (69), 31-Янв-22, 18:00

Так снижается же цена сопровождения наоборот, по сравнению с "опасной процедурой на встроенном ассемблере, экономящей 50-100 раз время выполнения"

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

73. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Анонн (?), 31-Янв-22, 17:23

Цена чего? Покажи пример большого оверхеда.
Ты можешь завернуть критический участок в ансейф, написать "мамкой клянусь тут нет race" и говнокодить как хочешь. Просто тебе попросят это доказать.
Можешь сделать вставку на асме. Делается так же элементарно (и тоже разумеется unsafe)
Если цена отсутствия всяких хардблидов или получений рута - отправить на пенсию пару старперов-неосиляторов, то это не большая цена.
Тебя не ограничивают ни в чем.

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

82. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Урри (ok), 31-Янв-22, 17:53

> Цена чего?
Разработки и сопровождения.
> Ты можешь завернуть критический участок в ансейф ...
> ... Просто тебе попросят это доказать. ...
> ... Тебя не ограничивают ни в чем.
у вас, растоманов, совсем каша в голове. Я так и не понял - раст не дает говнокодить или никак не препятствует? И чем это отличается от С, где точно так же можно говнокодить, а можно и нет.
Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе?
В чем плюс то? В том, что можно мозги не включать?
> отправить на пенсию пару старперов-неосиляторов
Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании не получится (разве что уже когда маразм придет).

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

86. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (69), 31-Янв-22, 18:06

> Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе?
Ниже Ordu писал о проблеме - проблема в семантике Си, в которой очень многое, с теми же умными указателями, возможно выполнять только в рантайме вместо компайл тайма. Если бы в Си была куда строже семантика, с куда более строгим отношением к UB, тогда дело иное. Вот потому анализатор и должен быть в компиляторе, и язык должен иметь куда более строгое отношение к UB и подобной ерундистике

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

87. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Анонн (?), 31-Янв-22, 18:21

Ну и где примеры высокой цены "Разработки и сопровождения" на расте?
То что научиться писать на Си можно  ̶л̶ю̶б̶у̶ю̶ ̶о̶б̶е̶з̶ь̶я̶н̶у̶  студента пту мы знаем. А вот найти крутого Си программера - ой какая проблема, потому что даже мЭтры из ядра линя лажают на таких простых вещах.
А у раста входной порог выше - не каждый сишник осилит ownership и borrowing. Зато потом существенно меньше багов с памятью.
> Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе?
Ну сменишь ты компилятор, даже заставишь это даже компилироваться, а потом внезапно окажется что его разрабы по-другому реализовали серые места стандарта и твой результат изменился на противоположный. Прекрасно ведь!
А плюс в том, что тебе на этапе компиляции рассчитывается владение и заставляют или исправить баги, или явно сообщить что ты гарантируешь это. Раст не дает говнокодить втихаря. В отличие от...
Есть прекрасная вещь - Clang Static Analyzer, который на минуточку является часть clang. И что?
> Написал человек, не понимающий разницу между компилятором и анализатором.
Фиг его знает где ты это прочел, но спишем уже на старческий маразм.

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

99. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (-), 31-Янв-22, 20:44

> Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж
> нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании
> не получится (разве что уже когда маразм придет).
-

1.2 The Structure of a Compiler
1.2.1 Lexical Analysis
1.2.2 Syntax Analysis
1.2.3 Semantic Analysis
s 608
Most global optimizations are based on data-flow analyses,
hich are algorithms to gather
information about a program.
The results of data-flow analyses all have the same form:
for each instruction in the program, they specify some
property that must hold every time that instruction is executed.
...
For example, a constant-propagation analysis computes,
for each point in the program, and for each variable
used by the program, whether that variable has a unique
constant value ...
И правда, кто такие
"Alfred V. Aho, Columbia University
Monica S. Lam, Stanford University
Ravi Sethi, Avaya
Jeffrey D. Ullman"
из "Compilers Principles, Techniques, & Tools", да супротив Урри, "Оупеннут Юниверсити"?!

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

100. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –3 +/–

Сообщение от Урри (ok), 01-Фев-22, 00:22

Когда закончились аргументы, побежим размахивать "авторитетами".
Слив засчитан, молодец.

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

102. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (-), 01-Фев-22, 03:31

Когда Урри опять с умным видом пyкнул в лужу, демонстрируя незнание азов и _общепринятой_ терминологии и побежал размахивать "сливом".

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

68. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от анонимус (??), 31-Янв-22, 16:22

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

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

70. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (69), 31-Янв-22, 16:38

Не спорю, но чем больше у нас проверок на ранних этапах, тем лучше. Надеяться только на CI - уже попахивает костылищем

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

8. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +2 +/–

Сообщение от Аноним (8), 31-Янв-22, 12:13

ну нафиг, если они такие умные то рано или поздно выйдут из под контроля и образуют скайнет

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

11. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Жироватт (ok), 31-Янв-22, 12:17

"Ты чё, умный дох*я? А, указатель? Память есть? А если найду?"

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

28. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (8), 31-Янв-22, 13:00

память как бы не его, он на неё показать токмо и может

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

30. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от bOOster (ok), 31-Янв-22, 13:06

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

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

47. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +13 +/–

Сообщение от Ordu (ok), 31-Янв-22, 14:07

Там же только uniq_ptr и shared_ptr, причём со всеми граблями C++'овых аналогов, типа "никаких гарантий". Например, uniq_ptr может быть NULL, то есть просто взять и разадресовать его, не проверяя на NULL -- это лишь до первого бага, который положит NULL туда, где NULL быть не должно.
Более того, насколько я вижу, эти указатели реализованы на _рантайм_ проверках, и более того эти рантайм проверки должны выполняться клиентским кодом. То есть, не, он может не проверять, и в случае ошибки в коде получит в рантайме разадресацию NULL с вытекающим из неё сегфолтом. Это _динамическая_ типизация в статически типизированном языке. В C++ тоже с этим проблемы вылезают[1]. Более того, если присмотреться[2], то проблема вытекает из свойств C и C++, которые делают невозможной move-семантику с compile-time проверками на то, что значение было перемещено, и поэтому программист, реализуя move constructor _вынужден_ обеспечивать своему типу специальное значение, которое семантически можно описать фразой "value was moved out, nothing to see here, go away", чтобы это значение можно было бы проверить в рантайме. А это означает, что uniq_ptr будет by design иметь значение NULL, и значит что если разадресовывая его ты забыл проверить на NULL, то значит ССЗБ.
[1] https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
[2] https://www.thecodedmessage.com/posts/cpp-move/
И это фундаментальная проблема, которая делает "умные" указатели бессмысленными в C и C++. Они не столько предотвращают ошибки, сколько снимают часть бойлерплейта, необходимого для того, чтобы избежать ошибок, и таким образом заметают потенциальные проблемы под ковёр, делают их менее заметными. Именно поэтому в ядре использовать uniq_ptr невозможно: в ядре всё в принципе по-возможности делается явным, чтобы было видно что происходит. Ядро пишется на C, и идеология написания кода ядра заточена под C: на компилятор нельзя полагаться, можно полагаться только на себя. Чтобы понять это, я могу порекомендовать Торвальдса, кормящего C++ тролля[3], где его ключевой тезис сводится к:
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
   that STL and especially Boost are stable and portable is just so full
   of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
   you notice that some abstraction wasn't very efficient, but now all
   your code depends on all the nice object models around it, and you
   cannot fix it without rewriting your app.
[3] https://harmful.cat-v.org/software/c++/linus
То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app. А подход C++ не работает довольно часто, потому что он не устраняет ни одной проблемы C, он лишь декорирует их кружевами, позволяя в 90% случаев делать вид, что это не баг, а фича. Но в оставшихся 10% тебя ждут те самые infinite amounts of pain. И смарт-поинтеры, реализованные в C, не нужны в ядре по той же самой причине. Они не снимают ни одной проблемы: тебе точно так же придётся своими глазами следить за тем, чтобы не разадресовать нечаянно указатель, который был куда-то перемещён. Сама операция перемещения dst←src, с последующим обнулением src, будет чуть проще записываться, но следить за тем, чтобы не обращаться к src после перемещения ты точно так же будешь глазами. А каждый твой фейл будет приводить к рантайм краху. Это не делает программирование проще: проследить глазами за обнулением src проще, чем за тем, чтобы он потом не использовался.
А если пытаться сделать всё хорошо и статически проверять все эти uniq_ptr, дабы не выносить проверки в рантайм, то:
> if you try to statically detect such situations, you end up with Rust.[4]
[4] https://www.foonathan.net/2017/09/destructive-move/
Упс. И статические анализаторы не спасут C и C++, потому что эти языки не кодируют в своих API тех допущений, которые необходимы этим API для работы. Теоретически можно было бы API дополнять комментами (примерно как в некоторых динамических языках запиливают статическую типизацию, описывая типы в комментах), но хмм... я не уверен, что это сработает. Теоретически -- да, должно быть возможно, но практически, мы получим две одновременно действующие системы типов, и я подозреваю, это кончится таким уродством и ногу-сломишь-в-этом-коде, что нахрен никому не нужно. Проще лишнюю рантайм проверку вставить, и выкинуть панику если NULL оказался там, где его быть не должно.

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

51. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +7 +/–

Сообщение от Аноним (51), 31-Янв-22, 14:44

Как поставить 100 плюсов?)

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

58. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (1), 31-Янв-22, 15:08

Браво за детальный ответ, сударь!

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

77. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (46), 31-Янв-22, 17:28

А ещё C++ абстракции не бесплатны.
Например инициализация памяти с помощью конструкторов, которые вызывают конструкторы member-членов, которые вызывают ... ну вы поняли.
Вместо того чтобы инициализировать кусок памяти разом и туда запихнуть весь layout структуры.
В Zig отказались от (супер)быстрого pattern-matching. Потому что if else всё равно быстрее (до 10 раз).
И компиляторы не способны в оптимизацию таких случаев как более простые и понятные конструкции.
Поэтому до сих пор С быстрее С++.
И, конечно, абстракции С++ текут. Например деструктор (и в нём надо защищаться от exception, использовать try / catch, и ... дальше у Майерса почитать).
Получается лютый говнокод.

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

84. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Урри (ok), 31-Янв-22, 18:01

Но я как бы и не говорил что умные указатели - серебряная пуля. Любой задаче, само собой, свои решения.
Отличный ответ, без сомнения. За исключением некоторых моментов:

> То есть всё сводится к тому, что пока C++ подход работает, всё хорошо, но когда он не работает, ты впарываешься в infinite amounts of pain и в rewriting your app.
Это онтосится ко всем языкам и парадигмам программирования без исключений.
> А подход C++ не работает довольно часто,
А вот это совершенно не так. Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого.
> позволяя в 90% случаев делать вид, что это не баг, а фича.
И снова аргумент разбивается о реальность.

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

111. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Прохожий (??), 03-Фев-22, 02:55

>Но я как бы и не говорил что умные указатели - серебряная пуля.
Зато ты постоянно говорил, что умные указатели в плюсах - это так же эффективно и круто, как в Раст. Оказалось - нет. А ещё говорил, что сообщество Раст тупое. И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в плюсах, и твоей любимой сишечке на самом деле. Ну и кто тут идиот теперь?
>Это онтосится ко всем языкам и парадигмам программирования без исключений
Я давно заметил, думать и приходить к правильным выводам - не твой конёк. Это никак не относится к низкоуровневым языкам. От слова совсем. Разжевать или сам поймёшь, почему так?
>Посмотрите на количество сложнейших проектов на С++ - они мало того, что работают. Так еще и в сопровождении стоят милосердно недорого.
Никто не знает, чего это стоило их авторам. Попадалась статья как-то, где один спец оптимизировал софт на крупной международной бирже. Ему одному в итоге удалось сделать на F# за полгода то, что десяток плюсовиков не могло сделать несколько лет. Скорость реакции софта выросла в несколько раз. Причина тормозов - излишняя сложность плюсов в местах, где нужна была высокая конкурентность вычислений.

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

116. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Урри (ok), 14-Фев-22, 12:50

> А ещё говорил, что сообщество Раст тупое.
Да. И продолжаю это говорить.
А сообщество в каждой новости это подтверждает.

> И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в
> плюсах, и твоей любимой сишечке на самом деле.
А ведь ты даже не понял что там написано, правда?

> Ну и кто тут идиот теперь?
Ты.

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

> Ну и кто тут идиот теперь? #2
Ты. #2

> Попадалась статья как-то, где один спец оптимизировал ... за полгода то, что десяток плюсовиков
> не могло сделать несколько лет.
Вот. Ты даже не понимаешь что такое "программный продукт" и что нельзя переносить свой опыт хелловорлда на разработку больших сложных вещей. Статья ему попадалась...
> Ну и кто тут идиот теперь? #3
Ты. #3
--
Видишь? Я был прав во всем.

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

118. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Прохожий (??), 16-Фев-22, 01:47

> Да. И продолжаю это говорить.
> А сообщество в каждой новости это подтверждает.
Не забывай в зеркало почаще смотреться. Ты гораздо хуже.

>> И вот тебе один из членов этого сообщества объяснил на пальцах, как все работает и в
>> плюсах, и твоей любимой сишечке на самом деле.
> А ведь ты даже не понял что там написано, правда?
Я-то прекрасно понял. Там понимать особо нечего. Рантайм-проверку один типа специалист Урри пытался приравнять проверке на этапе компиляции. Сидиоты, они такие.
> Я знаю. Я за свою жизнь поучаствовал в немалом количестве сложнейших проектов
> на С++,
В роли зрителя? Вряд ли это можно считать поводом для гордости.
> а уже скоро как большую часть этого времени даже
> составлял сметы и для самих проектов и для их сопровождения.
А, так ты экономист-бухгалтер. С этого и следовало начинать.
То, что ты создавал видимость активной работы, я не сомневаюсь. Но глядя на твои выперды на этом форуме и удручающе незнание предметной области, сильно сомневаюсь, что такая активность была сколь-либо эффективной.
> Вот. Ты даже не понимаешь что такое "программный продукт"
Тебе бы, дурачку, мне рассказывать про программные продукты. Я в этой индустрии уже второй десяток лет работаю с крупными клиентами по всему земному шарику.
> Видишь?
Вижу. Гнать подобных тебе "спецов" подальше из профессии ссаными тряпками.

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

88. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (88), 31-Янв-22, 18:26

Ладно крах при разименовывании NULL. Но от "что позволяло добиться выполнения своего кода на уровне ядра." как-то можно принципиально избавиться в таких случаях?

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

50. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Анонн (?), 31-Янв-22, 14:15

А толку что есть? Их все равно никогда (при жизни Линукса, по крайней мере) не затащат в ядро.
Проект новье (вроде с 2016 года, но не точно). Не обкатано, не проверено. Еще и по MIT License.
PS: О, неужели до сишников таки дошло что автоматическое управление памятью это хорошо?

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

85. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от Урри (ok), 31-Янв-22, 18:03

> PS: О, неужели до сишников таки дошло что автоматическое управление памятью это
> хорошо?
Сишники, вообще-то, знают когда автоматическое управление памятью хорошо, а когда плохо. Для хорошо у них даже куча реализаций GC есть.
https://github.com/mkirchner/gc

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

110. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Прохожий (??), 03-Фев-22, 01:48

Q. Can I use this on a serious project ?
A. Yes, but as this project has not been widely used, there might be some bugs. Beware!
А ещё эта хрень зависит исключительно от одного свойства компилятора gcc, насколько я понял. То есть, для других компиляторов может не работать.

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

117. Скрыто модератором +/–

Сообщение от Урри (ok), 14-Фев-22, 12:52

Для растоманов все еще новость, что библиотеки могут быть разными.
Я привел один из примеров библиотеки с умными указателями на С. Таких примеров можно найти десятки. Некоторые даже используются во внутренних кухнях больших проектов.
Вон там выше аноним упрекал меня в том, что я утверждаю что сообщество растишек идиоты. Так вот, жизнь каждый раз это подтверждает. Как, например, прямо сейчас.

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

4. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от макпыф (ok), 31-Янв-22, 12:08

> user namespace
Второй ebpf

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

10. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (10), 31-Янв-22, 12:15

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

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

13. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от макпыф (ok), 31-Янв-22, 12:33

всм? оба отключаются.
Я про решетo, половина уязвимостей в ядре - ebpf и userns
P.S. Почему ворд вильтер агрится на "решетo"

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

21. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (10), 31-Янв-22, 12:49

как отключить ebpf в актуальном ядре?

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

22. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от макпыф (ok), 31-Янв-22, 12:52

> как отключить ebpf в актуальном ядре?
# CONFIG_BPF_SYSCALL is not set
# CONFIG_BPF_JIT is not set
CONFIG_BPF как я понял ни на что не влияет
Алсо, в актуальном ядре оно запрещено непривелигерованным пользователям

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

24. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (10), 31-Янв-22, 12:55

Это не ebpf. В выводе видно на что он влияет, но он тоже не отключается больше
CONFIG_BPF=y
# CONFIG_BPF_SYSCALL is not set
CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_BPFILTER is not set
# CONFIG_BPF_JIT is not set
CONFIG_HAVE_EBPF_JIT=y

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

27. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от макпыф (ok), 31-Янв-22, 13:00

> Это не ebpf.
cbpf мертв, не помню удалили его полностью или нет, но всегда используется ebpf
> CONFIG_BPF=y
Инклюдит мейкфайл bpf
> # CONFIG_BPF_SYSCALL is not set
Это оно как раз
> CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
> CONFIG_HAVE_EBPF_JIT=y
Это значит что архитектура поддерживает ebpf jit
> # CONFIG_NETFILTER_XT_MATCH_BPF is not set
> # CONFIG_BPFILTER is not set
> # CONFIG_BPF_JIT is not set
Эти забыл, да.
> он тоже не отключается больше
Все норм отключается, и на мастере, и на next, и на 5.16

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

34. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (10), 31-Янв-22, 13:17

Раньше можно было убрать любые упоминания(

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

40. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (26), 31-Янв-22, 13:31

>  как отключить ebpf в актуальном ядре?
Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную группу, практически per-appliaction firewall.
А вот для не-рута надо запрещать, да.

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

96. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от макпыф (ok), 31-Янв-22, 20:27

> Нафига? Удобная же штука. Можно создавать правила фильтрации айпишников на контрольную
> группу, практически per-appliaction firewall.
Ну не всем и не всегда это требуется
> А вот для не-рута надо запрещать, да.
В принципе, в 5.16 так и сделано по дефолту

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

65. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (65), 31-Янв-22, 15:57

> P.S. Почему ворд вильтер агрится на "решетo"
Если бы вы увидели список всего, на что агриться это чудо, то вы бы истерично смеялись, потом плакали, потом опять плакали...
Просто примите пожалуйста, что на опеннете правила фильтрации "очень особенные", и не вдавайтесь в подробности и не зацикливайтесь, а то ещё больше будет мнений, что создавали это чудо также "особенные", со своим видением мира!
Проще пользоваться с поправкой на это, чем пытаться вникнуть, разобраться и тем более что-то исправить, даже обсуждение этого ни к чему хорошему не приводит, а нервные клетки не восстанавливаются, разумнее принять и продолжать пользоваться как есть не думая о "красно***ой обезьяне"!

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

16. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноньимъ (ok), 31-Янв-22, 12:38

>речь просто об ошибке в ядре
Всего-то на всего. Тьфу ерунда.

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

23. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (10), 31-Янв-22, 12:54

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

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

35. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (35), 31-Янв-22, 13:18

первый.
Лет десять уже этой попытке сделать чтоб вот любой юзер был как рут, но не совсем. На пол-шишечки.
Опыт винды (где это даже не считается уязвимостью) ничему не научил. Вернее, научил все тому же - "мне двойное то же самое что тому джентльмену!"

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

61. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от псевдонимус (?), 31-Янв-22, 15:23

Первый хронологически.

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

5. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (10), 31-Янв-22, 12:10

sysctl: cannot stat /proc/sys/kernel/unprivileged_userns_clone: No such file or directory
CONFIG_USER_NS=y
что надо включить?

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

9. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –5 +/–

Сообщение от Аноним (6), 31-Янв-22, 12:13

>Проблема проявляется начиная с ядра Linux 5.14
>linux-image-generic/impish-updates,impish-security,now 5.13.0.27.37 amd64 [установлен, автоматически]

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

43. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +3 +/–

Сообщение от НяшМяш (ok), 31-Янв-22, 13:40

Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого патча и гордится этим.

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

66. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +3 +/–

Сообщение от Аноним (65), 31-Янв-22, 16:01

> Наконец-то настоящий эксперт опеннета. Пользуется неподдерживаемым ядром без единого
> патча и гордится этим.
Актуальные бунту ядра поддерживаются самой канониклой, а вот насколько эта сикурити-поддержка качественная, это уже другой разговор, не нужно ссылаться на то, что ядра бунт уже EOL в kernel.org, что у Debian подобная практика имеется, что у красношляпы.
Я удивлён, что вы про это не знали, или если это такой наброс с вашей стороны, также удивлён, вроде такой сурьёзный мужчина?!

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

93. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от НяшМяш (ok), 31-Янв-22, 19:17

> а вот насколько эта сикурити-поддержка качественная
Меня смущает тот факт, что патч версия у Анонима (6) до сих пор 0, хотя на кернел.орг последний патч для этой версии был 9. И тут есть два варианта - либо они нарушают версионирование (что плохо), либо они не обновляют патч версии из апстрима (что тоже плохо). В общем, убунтыдебианы сами себе проблем создают, вместо того чтобы использовать LTS с кернел.орг
> вроде такой сурьёзный мужчина?!
Вот это уже обидно было. Был бы я серьёзным - не страдал бы фигнёй на опеннете xD

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

94. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от mikhailnov (ok), 31-Янв-22, 20:01

У убунты ядро всегда версии x.y.0, они много чего в него переносят, не поднимая 0, иначе бы их версия, допустим, 5.13.6 не соответствовала бы настоящей 5.13.6.

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

15. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –5 +/–

Сообщение от Аноним (46), 31-Янв-22, 12:34

Вот и разбиваются доводы Военов АнтиРастового Сопротивления о суровую реальность и кучи уязвимостей.
Не могут даже ucount безопасно отрефакторить, отличный язык.
JavaScript получше будет.

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

17. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (17), 31-Янв-22, 12:44

А вы спрашиваете, зачем стейбл во времена блидинг эджей.

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

18. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от Шарп (ok), 31-Янв-22, 12:44

>use-after-free
пикачу^Wrust - я выбираю тебя!

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

31. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +3 +/–

Сообщение от Аноним (14), 31-Янв-22, 13:10

А C# уже всё, не в моде?

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

89. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (88), 31-Янв-22, 18:29

Будето там такого нельзя. При желании тоже можно звать объект после вызова деструктора.

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

36. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от Аноним (36), 31-Янв-22, 13:20

А что не питон?

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

45. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от Fracta1L (ok), 31-Янв-22, 13:48

> продолжали использоваться после освобождения выделенной для них памяти (use-after-free)
Захохотал

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

48. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (46), 31-Янв-22, 14:08

Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free?
Погонять на устройствах, отловить такие баги, часть хотя бы.
Походу дела ядро вообще не тестируют.
Вроде что-то похожее использует в Zig.

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

55. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от Аноним (55), 31-Янв-22, 14:50

> Походу дела ядро вообще не тестируют.
Ядро тестируют на пользователях, это официальная позиция корпораций-разработчиков.

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

112. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от anonymous (??), 03-Фев-22, 11:57

> Неужели нельзя собрать тестовое ядро с кастомным аллокатором, которое отслеживает use-after-free?
Для этого нужно прогнать через всевозможные сценарии использования и окружения. Иначе можно и не поймать.

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

54. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (55), 31-Янв-22, 14:48

> Redox is a Unix-like Operating System written in Rust
Да, я тоже посмеялся.

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

71. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (-), 31-Янв-22, 16:43

>> Redox is a Unix-like Operating System written in Rust
> Да, я тоже посмеялся.
Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого Вторжения"?

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

92. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от самокатофил (?), 31-Янв-22, 19:16

>>> Redox is a Unix-like Operating System written in Rust
>> Да, я тоже посмеялся.
> Там тоже use-after-free нашли или опять Воены Растового Сопротивления сначала приплетают
> раст, чтобы затем дружно и мощно пук^W "защитить Голактеку от Ржавого
> Вторжения"?
>"Redox is not correct, secure, or documented. It does a lot of things in a cavalier, leave it up to the application, manner. Applications can malloc and forget to free, Redox will not clean this up. Applications can access missing memory or kernel memory, Redox does not care. All applications run in Ring 0, and have all permissions. Some syscalls use vtables that rely on exactly the same struct defintions in userspace as kernel space. Syscalls cannot return values, except by writing them into a passed pointer. Memory allocation is done in the application, and uses a global memory allocation table that applications directly modify. None of its functionality is documented, outside of example source files." -- https://redox-os.org/
Гениально, Карл! С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом. А учитывая что этому хелловорду даже CVE присваивать стыдно -- то можно с уверенностью сказать, что редох это флагман безопасности осестроения растаманек. :-D

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

113. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от anonymous (??), 03-Фев-22, 12:02

> С такими вводными не то чтобы use-after-free, я даже не знаю что в редохе считать багом.
Если не знаете -- это понятно. Но вы не увиливайте: там use-after-free много уже нашли или нет?

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

109. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (14), 02-Фев-22, 21:07

Rust-то такого не позволяет. Он просто память не освобождает, потому и нет use-after-free.

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

114. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от anonymous (??), 03-Фев-22, 12:04

В смысле "не освобождает"? Вы про что? Можно так же ссылку на первоисточник? И напомню, что вы сказали про Rust, а не про Redox.

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

49. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +2 +/–

Сообщение от Анонн (?), 31-Янв-22, 14:11

Йохохо, всего два дня прошло с предыдущей дыры, а тут уже новая подоспела. И опять повышение привилегий, и опять налажали с памятью.
Стабильность признак мастерства!

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

53. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аниме (?), 31-Янв-22, 14:46

Растовчане то так не могут, что за неудачники

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

64. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от DD (??), 31-Янв-22, 15:38

Янукович & Co?

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

60. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от псевдонимус (?), 31-Янв-22, 15:16

И снова неймспейсы. Эта музыка будет вечной.

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

63. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +5 +/–

Сообщение от RAMbug (?), 31-Янв-22, 15:32

И снова перекидывания фекалиями фанатиков раста и сишечки.
Дело не в том, что какой-то из этих языков лучше или хуже, а в том, что ядро Linux — это 30-летний поток монолитного говнокода без какого-либо намёка на продуманную архитектуру и контроля за качеством.

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

98. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от nvidiaamd (?), 31-Янв-22, 20:31

И тут ты такой из-за угла с продуманной архитектурой. Что, нету? Странно.

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

72. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от самокатофил (?), 31-Янв-22, 16:50

Растаманьки, скажите, а правда что в расте невозможен use after free по определению? :-)
lynx -dump 'https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust' | grep -A1 -B1 'use-after-free' --color

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

91. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –2 +/–

Сообщение от Аноним (-), 31-Янв-22, 19:04

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

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

101. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +1 +/–

Сообщение от x3who (?), 01-Фев-22, 03:08

> автоподрыв ракет
Да ладно, всё решается избыточностью - запускаем, допустим, пять контейнеров, в каждом из которых независимо крутятся программы управления ракетой, написанные независимыми группами разработчиков  на расте, электроне, сиплюсплюсе, петоне и джаво. Сверяем сигналы управления, которые генерируют эти программы. Если, допустим, какой-то контейнер выдал на элерон №1 управляющий сигнал, на N% отличающийся от того, что выдало большинство сервисов, то перезапускаем проштрафившийся сервис, сигналы от остальных усредняем. Если кворума вообще никакого нет, т.е. все пять сервисов выдают сигналы с разбросом более N%, то отключаем нафиг всю эту халабуду и летим как деды летали - на резервном контроллере, запрограммированном на сишечке..

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

115. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от www2 (??), 14-Фев-22, 07:50

Скорее всего получится ситуация "а вы друзья, как ни садитесь, всё в музыканты не годитесь" и ракета всё-таки полетит на резервном контроллере, запрограммированном на сишечке. Но в пресс-релизах будет только пятикратный кворум, встроенный кубернетес и прочее вот это вот всё. Иначе не получится распиливать.

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

103. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от soup2 (?), 01-Фев-22, 08:32

Теперь будет Rust Kernel за место Linux Kernel xDDDDDDDD

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

105. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." –1 +/–

Сообщение от Аноним (105), 01-Фев-22, 13:04

что-то в винде меньше дырок чем находят в linux kernel..

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

108. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..." +/–

Сообщение от Аноним (108), 02-Фев-22, 00:46

Вы не поверите - у винды исходники закрыты, поэтому приходится страдать и искать уязвимости в отладчиках и дизассемблерах с гораздо меньшей эффективностью, но гораздо более тяжёлыми последствиями. Вероятность того, что найдут zero day, который поставит раком половину планеты, как шифратор Petya через SMB протокол, сильно выше, чем в линуксе.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–8 +/–
Сообщение от Аноним (1), 31-Янв-22, 12:06
Ну что, кто-нибудь ещё скажет что-нибудь после такого о превосходстве Сишников? То-то же! Раст всем голова.
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+11 +/–
	Сообщение от Урри (ok), 31-Янв-22, 12:08
	Я тебя даже плюсанул. Вполне неплохой наброс.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+9 +/–
	Сообщение от Аноним (26), 31-Янв-22, 12:58
	Такой неплохой наброс можно писать под каждой новостью про очередную сишную дыру. То есть минимум раз день.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	38. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+4 +/–
	Сообщение от Урри (ok), 31-Янв-22, 13:29
	И это хорошо! Приятно начинать день с чашечки вкусного кофе и приятных набросов на опеннете. После чего, наконец проснувшись подняв себе настроение, можно и за кодинг на сишечке браться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	41. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+7 +/–
	Сообщение от Аноним (26), 31-Янв-22, 13:32
	С мыслью "этому миру нужно больше дыр".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Аноним (46), 31-Янв-22, 14:03
	До слёз ;)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	95. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от malloc (?), 31-Янв-22, 20:05
	Говори за себя, дыра.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	14. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–5 +/–
	Сообщение от Аноним (14), 31-Янв-22, 12:34
	Головка.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	57. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от DD (??), 31-Янв-22, 14:59
	Вертеть?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Аноним (90), 31-Янв-22, 18:30
	"Безопасный язык" только предотвращает ситуации, от которых всё падает. Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код. И так как мышление становится пережитком прошлого -- как легко видеть из ситуации с растохайпом -- то бэкдоры служить будут сильно дольше, а внедрение их обойдётся значительно дешевле. Поэтому раст выгоден. Поэтому хайп будет нарастать.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	104. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+2 +/–
	Сообщение от Аноним (104), 01-Фев-22, 10:21
	> Это значит, что у раста баги будут менее заметны, поэтому для их выявления придётся больше думать и серъёзнее анализировать код. Это значит что и у Си после вычесывания (удачи!) типичных ошибок переполнениями и т.п. (которых 70%), допущенных наСильниками, останется 30% ошибок, "для выявления которых придётся больше думать и серъёзнее анализировать код". Только еще хуже - в типичной Си-шной многопоточке еще дополнительный ворох нетривиальных проблем подбрасывается (всякие рэйс-кондишоны), в отличие от типичной многопоточки Раста с его понятием владения, по дефолту взаимодействием посредством передачи сообщений и пр. (хотя на Расте тоже можно при желании в сишном стиле написать, с разделяемыми между потоками данными и объектами синхронизации и поиметь тот же ворох проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код").
	Ответить \| Правка \| Наверх \| Cообщить модератору


	106. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Аноним (-), 01-Фев-22, 17:34
	> (хотя на > Расте тоже можно при желании в сишном стиле написать, с разделяемыми > между потоками данными и объектами синхронизации и поиметь тот же ворох > проблем, для исправления которых "придётся больше думать и серъёзнее анализировать код"). Ну вот! Видишь! И зачем тогда нужен этот ваш Раст? * пошел выкручивать из машины ненужные подушки и ремни безопасности вместе со смузихлебными ESC и ABS *
	Ответить \| Правка \| Наверх \| Cообщить модератору


	107. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Аноним (104), 01-Фев-22, 17:57
	так ведь "при желании"! Если есть желание "самоубиться" - пжалста! Но только наСильник будет пытаться упорно применять техники из Си в Расте.
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+1 +/–
Сообщение от Урри (ok), 31-Янв-22, 12:08
Для сишечки тоже есть умные указатели. Например, https://github.com/Snaipe/libcsptr Но в ядре их не используют.
Ответить \| Правка \| Наверх \| Cообщить модератору


	6. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Аноним (6), 31-Янв-22, 12:11
	Умные указатели для неумных людей.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+17 +/–
	Сообщение от ilyafedin (ok), 31-Янв-22, 12:21
	Умные люди, видимо, получают use-after-free уязвимости
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Аноним (81), 31-Янв-22, 17:33
	На раст уже редох написали. Ага, дайте две.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Аноним (1), 31-Янв-22, 12:12
	Ну это опционально, а нужно чтобы принудительно было, чтобы нельзя было забыть что-то где-то. Максимум компиляторногг контроля
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	39. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Урри (ok), 31-Янв-22, 13:31
	Не компиляторного. А со стороны непрерывной интеграции.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Аноним (1), 31-Янв-22, 14:59
	Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль. Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–5 +/–
	Сообщение от Урри (ok), 31-Янв-22, 15:14
	> Непрерывная интеграция обычно предполагает контроль пост-фактум, что есть костыль. Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда. Я бы вообще просто по фразе "CI - костыль" выпинывал из профессии назад в то ПТУ, где оного персонажа учили, на второй год. > Некорректный код не должен вообще даже компилироваться, даже бинарь надо не давать на выход Это корректный код? float sine(float x) { return cos(x); } а это? float enis(float x) { return cos(x); } Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+1 +/–
	Сообщение от Аноним (1), 31-Янв-22, 15:24
	> Это не костыль - это реальная жизнь и залог качества всего, что сложнее хелловорлда Да понятно дело, но ведь это обусловлено несовершенствами наших языков > Как будете обучать компилятор понимать то, что ни вы, ни я не в состоянии? По содержательным вещам - пишется спецификация и доказывается. Пример - seL4 Что же касается темы Си, Раста и всего такого - если можно вложить доп проверки, почему не вложить? Си пропустит такой кусок кода int * x; if <somecond> { int tmp = 1; x = &tmp; } хотя он явно не корректен и поймать это легко. Что Раст и делает и не допускает такой код
	Ответить \| Правка \| Наверх \| Cообщить модератору


	67. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Урри (ok), 31-Янв-22, 16:08
	> Да понятно дело, но ведь это обусловлено несовершенствами наших языков Берите шире - Вселенной. И это не стеб и не сарказм. > если можно вложить доп проверки, почему не вложить? Если при этом не ломать работающее, конечно же. Или вы так не думаете? > Что Раст и делает и не допускает такой код За цену этого "не допускает" не хотите поговорить? Ну то-есть как бы за все надо платить, не так ли? Или не важно? Я вот, например, от такого кода очень легко избавлюсь с помощью специального инструментария, называемого статическими анализаторами. При этом у меня остается свобода написания высокоскоростного кода. А у вас не остается. Вот если я предложу ради безопасности вашего ребенка (машина не собьет, маньяк не зарежет) поместить его навечно в дурку - вы согласитесь? Я думаю - нет. Вот и тут так же.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	69. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Аноним (69), 31-Янв-22, 16:37
	> При этом у меня остается свобода написания высокоскоростного кода. > А у вас не остается. Почему? Абстрактные рассуждения про цену звучат, конечно, классно, но где конкретные примеры того, что Раст даёт сильную просадку по производительности именно из-за запрета того или иного кода?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–2 +/–
	Сообщение от Урри (ok), 31-Янв-22, 17:29
	> где конкретные примеры того, что Раст даёт сильную просадку по производительности Узковато мыслите. Добавьте сюда "цена разработки" и "цена сопровождения".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+/–
	Сообщение от Аноним (69), 31-Янв-22, 18:00
	Так снижается же цена сопровождения наоборот, по сравнению с "опасной процедурой на встроенном ассемблере, экономящей 50-100 раз время выполнения"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+1 +/–
	Сообщение от Анонн (?), 31-Янв-22, 17:23
	Цена чего? Покажи пример большого оверхеда. Ты можешь завернуть критический участок в ансейф, написать "мамкой клянусь тут нет race" и говнокодить как хочешь. Просто тебе попросят это доказать. Можешь сделать вставку на асме. Делается так же элементарно (и тоже разумеется unsafe) Если цена отсутствия всяких хардблидов или получений рута - отправить на пенсию пару старперов-неосиляторов, то это не большая цена. Тебя не ограничивают ни в чем.
	Ответить \| Правка \| К родителю #67 \| Наверх \| Cообщить модератору


	82. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Урри (ok), 31-Янв-22, 17:53
	> Цена чего? Разработки и сопровождения. > Ты можешь завернуть критический участок в ансейф ... > ... Просто тебе попросят это доказать. ... > ... Тебя не ограничивают ни в чем. у вас, растоманов, совсем каша в голове. Я так и не понял - раст не дает говнокодить или никак не препятствует? И чем это отличается от С, где точно так же можно говнокодить, а можно и нет. Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе? В чем плюс то? В том, что можно мозги не включать? > отправить на пенсию пару старперов-неосиляторов Написал человек, не понимающий разницу между компилятором и анализатором. Ну куда уж нам, старперам, осилить такой уровень глупости и скудоумия. При всем старании не получится (разве что уже когда маразм придет).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	+1 +/–
	Сообщение от Аноним (69), 31-Янв-22, 18:06
	> Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе? Ниже Ordu писал о проблеме - проблема в семантике Си, в которой очень многое, с теми же умными указателями, возможно выполнять только в рантайме вместо компайл тайма. Если бы в Си была куда строже семантика, с куда более строгим отношением к UB, тогда дело иное. Вот потому анализатор и должен быть в компиляторе, и язык должен иметь куда более строгое отношение к UB и подобной ерундистике
	Ответить \| Правка \| Наверх \| Cообщить модератору


	87. "Уязвимость в механизме ucount ядра Linux, позволяющая повыси..."	–1 +/–
	Сообщение от Анонн (?), 31-Янв-22, 18:21
	Ну и где примеры высокой цены "Разработки и сопровождения" на расте? То что научиться писать на Си можно ̶л̶ю̶б̶у̶ю̶ ̶о̶б̶е̶з̶ь̶я̶н̶у̶ студента пту мы знаем. А вот найти крутого Си программера - ой какая проблема, потому что даже мЭтры из ядра линя лажают на таких простых вещах. А у раста входной порог выше - не каждый сишник осилит ownership и borrowing. Зато потом существенно меньше багов с памятью. > Тем, что в мире С - компилятор и анализатор разные программы, а раст - одна и та же, без возможности сменить либо компилятор, либо анализатор, либо и то и другое вместе? Ну сменишь ты компилятор, даже заставишь это даже компилироваться, а потом внезапно окажется что его разрабы по-другому реализовали серые места стандарта и твой результат изменился на противоположный. Прекрасно ведь! А плюс в том, что тебе на этапе компиляции рассчитывается владение и заставляют или исправить баги, или явно сообщить что ты гарантируешь это. Раст не дает говнокодить втихаря. В отличие от... Есть прекрасная вещь - Clang Static Analyzer, который на минуточку является часть clang. И что? > Написал человек, не понимающий разницу между компилятором и анализатором. Фиг его знает где ты это прочел, но спишем уже на старческий маразм.
	Ответить \| Правка \| К родителю #82 \| Наверх \| Cообщить модератору