- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 11:38 , 27-Мрт-24 (1) –9 [V]
>Работа эксплоита продемонстрирована в актуальных выпусках Debian и UbuntuПотому что там нет SELinux.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 11:47 , 27-Мрт-24 (2) +14 [^]
И как SELinux поможет от дыры в _ядре_?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:42 , 27-Мрт-24 (38)
Скачайте эксплойт и убедитесь сами.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:29 , 27-Мрт-24 (96)
> Скачайте эксплойт и убедитесь сами.И как SELinux защитит модуль ksmbd в ядре от запуска удалённо атакующего эксплоита, скаченного и запущенного на моей системе, если после эксплуатации дыры он выполнит код на уровне ядра и получает полный контроль на уровне ядра, т.е. при желании может вообще отключить этот SELinux и загрузить своё ядро?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:40 , 27-Мрт-24 (105)
В нормальных дистрибутивах отключение SELinux во время работы невозможно. Повторю совет попробовать эксплойт на Fedora и не выдумывать.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 17:34 , 27-Мрт-24 (120)
> В нормальных дистрибутивах отключение SELinux во время работы невозможно. Повторю совет попробовать эксплойт на Fedora и не выдумывать. Эксплоита для ksmbd ещё нет, пробовать нечего. В эксплоите к netfilter достаточно ограничить доступ к netfilter, но не о нём речь.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 10:11 , 28-Мрт-24 (162)
> В нормальных дистрибутивах отключение SELinuxПример такого дистрибутива в студию с пруфами о неотключаемости selinux Так же в студию требуются пруфы о том, что selinux может в перехват сетевых пакетов, прилетающих извне
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., pavlinux, 12:13 , 28-Мрт-24 (164)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:50 , 28-Мрт-24 (168) –1
> Так уж и быть, опущу очередного васяна анонимаТы случайно гну линуксом не пользуешься? Слишком уж дегенеративные набросы от тебя В твоей портянке нет ни одного поля, запрещающего принятие запроса для обработчика ksmbd в составе ядра
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:07 , 27-Мрт-24 (49) –2
> И как SELinux поможет от дыры в _ядре_?Ну, как, атакующему придется аж отметериться - и взять стандартный эксплойт с отключкой этой пакости. Потратит аж на 2 минуты больше.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:30 , 27-Мрт-24 (56) –4 [V]
В Fedora нельзя отключить SELinux.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:30 , 27-Мрт-24 (98)
> В Fedora нельзя отключить SELinux.Добившись выполнения кода на уровне ядра можно отключить что угодно.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:35 , 27-Мрт-24 (101) –2
Но с SELinux не получится добиться выполнения кода на уровне ядра.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:38 , 27-Мрт-24 (104)
> Но с SELinux не получится добиться выполнения кода на уровне ядра.Почему? SELinux защищает исключительно user space, а ksmbd работает в ядре, т.е. SELinux никак не помешает отправить ему пакет и добиться переполнения буфера в ядре.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 18:52 , 27-Мрт-24 (130) –1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 18:43 , 27-Мрт-24 (129)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., myster, 12:04 , 27-Мрт-24 (13)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 21:13 , 27-Мрт-24 (141)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ryoken, 11:48 , 27-Мрт-24 (3) –4 [V]
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., iPony129412, 12:06 , 27-Мрт-24 (15) –1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:12 , 27-Мрт-24 (52) +5
> тут Samsung криво-косо в режиме сро/аки горят реализовал протоколы MS - "вендотехнологий - зло"Конечно безопасная реалиазция smb без вулнов - это еще поискать, но перегруженый замордованый кодер с самсунговской галеры - таки насажал багов везде где мог. И даже не потому что плохой програмер или злодей. А потому что с 4 здоровыми проектами на 1 тушке без особой помощи от других так кто угодно зашьется. А в ядро это приняли чтобы совместынми усилиями, вот, разгрести за ними, ибо фича то нужная. Ну вот и разгребают.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., User, 14:59 , 27-Мрт-24 (80) +3
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:18 , 27-Мрт-24 (89) +1
Ну так это вопрос не к самсунгу и не к кодеру. А сообществу которое жадничает скинуться деньгами на зарплаты программерам. Хотя... у нас же ГКУ во все поля, а при коммунизме прогрмаммист денег должне получать немного, если вообще сможет выпросить в виде пожертвований.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., glad_valakas, 17:12 , 27-Мрт-24 (115) –1 [V]
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Sw00p aka Jerom, 08:56 , 28-Мрт-24 (159)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., 12yoexpert, 11:48 , 27-Мрт-24 (4) –11 [V]
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., iPony129412, 11:56 , 27-Мрт-24 (7) –2
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:03 , 27-Мрт-24 (12) +4
Ну так пошел бы и показал как нужно писать код. А то ты только языком треплешь на форуме.> засирают своими якобы CVE всё на свете Тебе уже готовый эксплойт принесли, но ты все равно не доволен
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:06 , 27-Мрт-24 (17) +1
> с тех пор, как мелкомягкие популяризовали линукс (а до них - космонавт)Да ладно тебе! Диды овнокодили в ядро еще 20 лет назад! И это периодически выгребают до сих пор.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Мухорчатый, 12:31 , 27-Мрт-24 (25)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Слава Линуксу, 17:14 , 27-Мрт-24 (118)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., нах., 20:09 , 27-Мрт-24 (138)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 07:26 , 28-Мрт-24 (152)
А обратно-обратно выбрать ему другую мировую линию развития, без systemd, Wayland, "и всё в /usr".
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 11:51 , 27-Мрт-24 (5) +3
>Выявивший уязвимость исследователь безопасности разработал и опубликовал рабочий прототип эксплоита, применимый к ядрам Linux начиная с выпуска 3.15 и заканчивая 6.8-rc1.Появятся новые рутуемые и перешиваемые устройства?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:08 , 27-Мрт-24 (18) +6 [^]
Тут главное чтобы рутовал ты, а не тебя) А то понапишут дыр в ядре, потом 100500 роутеров превращаются в ботнет.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:24 , 27-Мрт-24 (23)
Ну так сначала рутануть, а потом — перешить/брикнуть (в зависимости от разблокируемости загрузчика, не знаю, как с этим) через dd.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 07:29 , 28-Мрт-24 (153) +1
Чаще таки ботнеты из роутеров появляются от банального admin:admin, оставленного по умолчанию.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 11:53 , 27-Мрт-24 (6) +2
> Проблема вызвана двойным освобождением памяти (double-free)И как обычно дыряшечные проблемы! > в актуальных выпусках Debian и Ubuntu с ядрами Linux 5.14 - 6.6 Linux 5.14 - 30 авг. 2021 г Т.е. свои три+ года бекдор отработал)) > Уязвимость проявляется начиная с версии ядра Linux 3.15 Релиз - 8 June 2014. А они умеют играть в долгую. Бекдоры начали делать двухкомпонентными. И чск ни один из тыщщи глаз не заметил бажину за целых 10 лет!
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., сщта, 12:04 , 27-Мрт-24 (14)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:08 , 27-Мрт-24 (20) –1
Бэкдоры надо полагать были заложены сознательными инженерами с совестью, наш респект борцам.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:01 , 27-Мрт-24 (45)
> наш респект борцамБорцам за зарплату от АНБ? Не, ну ребята конечно молодцы, но достойно ли это наших респектов?.. Хотя если бы АНБ приходилось платить за каждую дыру, сделанную си погромистом, то они бы давно уже разорились бы.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:11 , 27-Мрт-24 (51)
За откаты АНБ работают индусы Майкрософт и Эпл, там никакой борьбы нет и всё на потоке. Тут борцы сражаются с корпорациями и их желанием всех посадить в клетку, к тому же, в отличие от уязвимостей проприетари, не эксплуатируется удалённо, так что совесть чиста. Всю историю его существования овнили линукс через netfilter, поэтому все, кому надо, найдут.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Пряник, 14:38 , 27-Мрт-24 (78) +1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:37 , 27-Мрт-24 (32)
10 лет - это ничего вообще-то.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:43 , 27-Мрт-24 (39) +1
И за 10 лет никто ей не воспользовался.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., вася, 13:01 , 27-Мрт-24 (46)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:09 , 27-Мрт-24 (50)
Ну так ты не пользуешься ОС, написанной исключительно тобой, ты пользуешься чужим продуктом - ядром линукс нахаляву, какие могут быть претензии с твоей стороны?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:48 , 27-Мрт-24 (61) +1 [V]
Кто пользовался? Пришельцы с Нибиру и они лично тебе об этом сообщили? Какую инфу через уязвимость выудил, надеюсь не ту что про госдолг?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., сщта, 11:57 , 27-Мрт-24 (9)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 11:58 , 27-Мрт-24 (10) –1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:06 , 27-Мрт-24 (16)
netfilter: bridge: replace physindev with physinif in nf_bridge_info netfilter: nfnetlink_log: use proper helper for fetching physinif netfilter: nf_queue: remove excess nf_bridge variable netfilter: nf_tables: check if catch-all set element is active in next generation netfilter: nf_tables: do not allow mismatch field size and set key length netfilter: nf_tables: mark newset as dead on transaction abort netfilter: nf_tables: reject invalid set policy netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description netfilter: nf_tables: skip dead set elements in netlink dump netfilter: nf_tables: validate chain type update if available netfilter: nft_limit: do not ignore unsupported flags netfilter: propagate net to nf_bridge_get_physindevв следующем обновлении было netfilter: nf_tables: reject QUEUE/DROP verdict parameters netfilter: nf_tables: restrict anonymous set and map names to 16 bytes netfilter: nf_tables: validate NFPROTO_* family netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain netfilter: nft_limit: reject configurations that cause integer overflow а потом netfilter: conntrack: correct window scaling with retransmitted SYN netfilter: nf_log: replace BUG_ON by WARN_ON_ONCE when putting logger netfilter: nf_tables: restrict tunnel object to NFPROTO_NETDEV netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations и netfilter: nft_compat: narrow down revision to unsigned 8-bits netfilter: nft_compat: reject unused compat flag netfilter: nft_compat: restrict match/target protocol to u16 netfilter: nft_ct: reject direction for ct id netfilter: nft_set_pipapo: add helper to release pcpu scratch area netfilter: nft_set_pipapo: remove scratch_aligned pointer netfilter: nft_set_pipapo: store index in scratch maps netfilter: nft_set_rbtree: skip end interval element from gc следом netfilter: ipset: fix performance regression in swap operation netfilter: ipset: Missing gc cancellations fixed а потом уже netfilter: conntrack: check SCTP_CID_SHUTDOWN_ACK for vtag setting in sctp_new netfilter: nf_tables: register hooks last when adding new chain/flowtable netfilter: nf_tables: set dormant flag on hook register failure netfilter: nf_tables: use kzalloc for hook allocation netfilter: nft_flow_offload: release dst in case direct xmit path is used netfilter: nft_flow_offload: reset dst in route object after setting up flow и теперь уже netfilter: bridge: confirm multicast packets before passing them up the stack netfilter: nf_tables: allow NFPROTO_INET in nft_(match/target)_validate() ну и конечно netfilter: nf_tables: do not compare internal table flags on updates netfilter: nf_tables: Fix a memory leak in nf_tables_updchain netfilter: nft_set_pipapo: release elements in clone only from destroy path и это получается всё бэкпортировано в 6.6 и не было сделано раньше
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:08 , 27-Мрт-24 (19) –2
как хорошо, что на моем диване ведро 5.10
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:21 , 27-Мрт-24 (22) +2
1. CVE-2024-1086 - double-free и поднять свои привилегии в системе. 2. CVE-2024-26592 - выполнения своего кода с правами ядра; вызвана состоянием гонки 3. CVE-2023-52440 - переполнение буфера из-за отсутствия должной проверки размера данных 4,5,6. CVE-2024-26594, CVE-2023-52442 и CVE-2023-52441 возвращение данных из области за границей буфера, отсутствие проверки входных данных, отсутствие необходимой проверки входных данных при обработке запросов SMB2. Из всей кучи дыр, можно только 2 отнести к логическим (и то если дать скидку на качество кода ядра). Остальные это "просто какой-то позор". Тебе пришли данные, ну проверь их размеры /_-
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:35 , 27-Мрт-24 (29)
У тебя комплексы или что? Какая разница что там за уязвимости? Если надо тебя всё равно взломают.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:03 , 27-Мрт-24 (47) +1
"У тебя комплексы или что? Какая разница что там за замки? Если надо тебя всё равно взломают."Поэтому просто выкинь все замки и защелки с дверей, окна тоже можно не закрывать. Всем расскажи какой у тебя номер банковской карты, пин и циферки на обороте! Ключи от тачки можно хранить прямо в бардачке, а еще лучше вешать на зеркало заднего вида. Откуда в такие вообще беретесь /_-
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:46 , 27-Мрт-24 (60) +2
Не очевидно что твоя замена понятий эквивалента. Попробуй ещё раз.В твоих замках тоже уязвимостей выше крыши и даже в окне. Поплач что твоё окно небезопасно. При том что даже к переписанной на р_ст двери отмычка подбирается за минуту. Ор с тебя выше гор.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 15:50 , 27-Мрт-24 (83)
>Не очевидно что твоя замена понятий эквивалента. Попробуй ещё раз. Зато очевидно, что ты не очень умный. Советую почитать побольше книжек. Ты сам пишешь > Какая разница что там за уязвимости? Если надо тебя всё равно взломают. Так что теперь их не фиксить? Или не обновлять ядро на новое? Или просто продолжать овнокодить, не добавлять проверок входных данных и лезть за границы буфера? Фигли, все равно взломают! Ты это имеешь в виду? > При том что даже к переписанной на р_ст двери отмычка подбирается за минуту. Пруфы, Билли! Тут нужны пруфы. А без них это просто пердеж в лужу. > Ор с тебя выше гор. Не удивительно, что такой недалекий как ты, все сводит к ору) А лучше бы почитал "как писать на дыряшке и не делать тупых ошибок"
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Карлос Сношайтилис, 14:46 , 27-Мрт-24 (79)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 06:20 , 28-Мрт-24 (150) +1
>Если на С писать правильно и со всеми проверками, он станет медленнее раста, в котором эти проверки вшиты и хорошо оптимизируются компилятором.ага, проверит размер поступивших токенов SMB2 Mech прям во время компиляции, и другие о%y№тельные истории от растаманов, о которых невозможно молчать. А если проверяет это в рантайме прям во время компиляции, лол, то зачем эти проверки кроме того что вшиты еще и оптимизируются компилятором? :-D
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Карлос Сношайтилис, 23:32 , 29-Мрт-24 (178)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 03:19 , 30-Мрт-24 (181)
>> проверит размер токенов SMB2 Mech > Вот тут ты прав, токены не проверит, а вот надо бы!тогда придётся подождать пока сиплюсплюсники запилят вам AILLVM. > Сишникам надо под каждую CVE новую версию компилятора выпускать, а то у > них с первого раза не получается фиксить. > А уж про всякие буферы и освобождение и говорить не приходится - > для матёрого сишника это как насморк - лечить не надо, само > пройдет. столько слов ниочем. :-D >> в рантайме ... во время компиляции > Непонятно, то ли ты только школу закончил, то ли на старости лет > таблетки забыл выпить. столько слов ниочем. >> эти проверки кроме того что вшиты еще и оптимизируются компилятором? > Даже не знаю что тебе посоветовать в такой тяжёлой ситуации. Ну почитай > что-нибудь базовое, "компиляторы для домохозяек" например. Там не сложно, даже для > школьников! столько слов ниочем. Ну вот скажи, и стоило так рвать дупу если нечего ответить?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:24 , 27-Мрт-24 (24) +1
Вопрос к экспертам русского языка. Вот это:> Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables и ksmbd для меня звучит как уязвимости, которым нужно/задействуют _одновременно _ "nf_tables и ksmbd". Будет ли более правильным написать: "Уязвимости в ядре Linux, позволяющие поднять свои привилегии через nf_tables или ksmbd" ?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:31 , 27-Мрт-24 (26)
лучше "по желанию поднять" Например, мне лень и я не буду поднимать, а кому-то может не лень...
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:34 , 27-Мрт-24 (28) –2
Нет, "и" вполне корректно, "или" выдаёт неносителя.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:00 , 27-Мрт-24 (43)
Родился русским, у русских родителей, живу в России всю жизнь, но хочется написать "или".
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:57 , 27-Мрт-24 (113)
Ну, страна большая, куча национальностей и местного колорита. Меня например забавляло как акают москвичи, а их как говорил мой коллега с кубани. А ведь есть еще кавказ, и восток, республика саха и тд. Ну и солевые со своими поребриками, гречей и парадным))На язык стандарт вроде есть, но на него все забивают... Что-то мне это напоминает :D
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:38 , 27-Мрт-24 (34)
Почему или, а не "а так же ksmbd". Но даже с "и" смысл понятен.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 19:12 , 27-Мрт-24 (132)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:33 , 27-Мрт-24 (27) +1
> Исправление уязвимости предложено в выпуске ядра Linux 6.8-rc1Это когда дерево упало и отключило электричество у Линуса и релиз 6.8-rc1 задержался. Т.е. они тихой цаплей думали как исправить дыры? Вот интересно, с прошлого релиза в linux-stable прошло 2 недели. Сейчас разом выкатили по всем веткам. Но 502 мешает затянуть изменения. Что в этот раз?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:36 , 27-Мрт-24 (30) +4
Не понимаю недовольства. Можно подумать, опеннетные эксперты в состоянии написать аналогичное ПО без уязвимостей.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:51 , 27-Мрт-24 (40) +2
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 13:39 , 27-Мрт-24 (57) +2
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:45 , 27-Мрт-24 (59) +2
> Я не знаю, что там было, когда всё это начиналось. Вполне возможно, что существовали веские причины. А поискал бы лучше. Там был убогий "си с классами". Который никаких плюсов (бадумтц) не давал, но добавлял нехилый оверхед в те темные времена первопней. > Хотя С++ позволяет делать ровно тоже самое, ... Нет, нельзя. С++ лучше по memory management чем си, но до раста ему топать и топать. В плюсах то что раст рассчитывает во время компиляции переносится в рантайм, а то что раст проверяет в рантайме в плюсах и так там живет. > ... при правильном использовании. А это вторая (или может быть даже первая?) проблема. Ты можешь использовать плюсы неправильно... и тебе за это ничего не будет. Ну может ворнинг вылезет.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 14:09 , 27-Мрт-24 (64)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:27 , 27-Мрт-24 (72) +3
> Важно то, что имеем сегодня.А сегодня мы имеем монстроспеку на 2к+ страниц)) > лично мне например и нужно, чтобы это было в рантайме, т.е. под моим, как программиста, контролем И жрет лишние время проца и оперативу. > При этом в случае с Rust - это дольше в разы, а выигрыш весьма сомнительный. Выигрыш как раз в том, что компиляешь ты один раз, а запускаешь софт - на порядки чаще. > Но на поверку - это лишь маркетинговая уловка. Голословное утверждение без пруфов которое подается как факт. Всё как я и люблю на опеннете)) > или добавить дополнительный модуль к компилятору того же С++, с ровно теми же функциями Но таких модулей еще нет. Вот когда появятся, тогда и поговорим. > Сделав при этом его опциональным И все будут его отключать потому что "а чаво оно ругается!" > С его мутными лицензионными ограничениями. Пруфы в студию. Уже второй раз пишешь про это. > программа будет вести себя +/- одинаково при использовании разных компиляторов Ахаха)) Ваши +/- это +/- километр. А потом люди спрашивают в интернетах "почему один и тот же код посла gcc и clang выдает различный результат" А потому что стандарт овно. "для того же С++ существуют международные стандарты" - и что, помогли они тебе?)) А у раста один компилятор. Который гарантировано будет работать как... как он сам. Круто же?)) > Ну так это проблема не языка, а квалификации программистов. Это проблема языка. Если язык, при некой степени сложности программы, начинает требовать от мясного мешка больше внимания к деталям, чем тот может позволить - то этот язык неприменим как надежный инструмент. С сишкой именно так и происходить. Писать хеллоуворды на нем легко и приятно. Но как только софт усложняется, то погромисты не в состоянии контролировать происходящее. И лучших ты не найдешь, потому что их не существует. Поэтому получается то что описано в этой новости. И решения тут условно два - или упрощать софт (что малореально), или автоматизировать валидации.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 15:21 , 27-Мрт-24 (82) –1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:17 , 27-Мрт-24 (88) +1
> Если хотите, чтобы всё было просто - добро пожаловать в каменный век. Не передергивайте. Мы сравниваем потенциальные плюсы и минусы замены сишки на один из двух языков. Мы как раз не хотим попасть в каменный век из-за одного залетевшего дятла. > А при использовании Rust не жрёт? Машинные инструкции в конечном итоге одни и те же. Нет, инструкции разные. Просто чтобы добиться эквивалентного кода в с++ вы напр. должны присвоить переменной null после освобождения памяти, чтобы потом не сделать double free. А в расте эту проверку сделает компилятор, который гарантирует что вы не сделаете double free. И присваивание не потребуется. И так еще в куче мест. > как уже написал выше - машинные инструкции везде одни и те же. То что вы так написали выше совсем не значит что инструкции одни и те же)) > "Умные" указатели это рантайм сущность. В расте они тоже есть. Но вам ничего не мешает в с++ читать и писать с любого потока просто в переменную. Ну будет пару рейсов, делов-то. А раст это не позволит - будет ошибка компиляции, где вам прозрачно намекнут что "или ты ошибся, или используй соответствующие примитивы синхронизации" > Впрочем, можете не приводить. Ну чего же вы так! Мне не сложно привести примеры)) codeproject.com/Questions/5331052/Cplusplus-different-output-on-different-compilers learn.microsoft.com/en-us/answers/questions/119430/different-results-in-different-compilers-c stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code qna.habr.com/q/1320980 ru.stackoverflow.com/questions/1508112/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83-%D1%80%D0%B5%D0%B7%D1%83%D0%BB%D1%8C%D1%82%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BD%D1%8B%D0%B9-%D0%BF%D1%80%D0%B8-%D0%BE%D0%B4%D0%B8%D0%BD%D0%B0%D0%BA%D0%BE%D0%B2%D1%8B%D1%85-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B0%D1%85-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0-%D0%A1 и тыщщи их А всё потому, что в распрекрасный стандарт с++ напихали undefined behaviour и implementation defined behaviour. Что гарантировано стреляет на лобой маломальски большой программе. Кроме того, погромисту нужно учить не только стандарт, но и все безумные реализации конкретных компиляторов. Вот поэтому стандарт плохой. > Для Rust уже больше одного компилятора. Насколько я знаю - нет. gccrs только разрабатывают и он еще не релизился. mrustc еще не релизился и это не generic compiler, а просто чтобы бустрапит раста. Ferrocene просто надстройка для rustc. > Всё можно, было бы желание. Значит у сишников нет желания?)) > любая автоматическая проверка тоже написана людьми. Да, но проверка будет занимать напр. 1000 строк кода. И проверять сотни тысяч строк с одинаковым качеством. А теперь посади погромиста вычитывать 100к сорцов. Посмеемся))
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 17:13 , 27-Мрт-24 (116) –1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 17:47 , 27-Мрт-24 (123) +1
> в С++ большойСтандарт. Плюс он написан так, что часть вещей просто UB, часть отдана на откуп реализатором компиляторов. Это всё нужно держать в голове при написании даже самого просто кода. И на это тратится время и внимание (которое тоже ресурс) программиста. > И, затем, совершенно сознательно не сделаю double free. О, как самоуверенно. Ну или у нас тут человек, который не совершает ошибок. Или кто-то что-то недоговаривает. > Ну т.е. один и тот же процессор способен выполнять... непредусмотренные изначально инструкции Вы ушли куда-то далеко. Мы говорим про инструкции самой программы. Что у вас для гарантии должна быть проверка на null, и если вы ее добавляете, то она будет в результирующем бинарнике. А в расте при тех же гарантиях проверка не нужна. А если вы на проверку забьете - то это ваше дело. > При этом опять же совершенно сознательно, где нужно (а бывает и такое), для ускорения работы не буду использовать примитивы синхронизации. А как вы гарантируете что к этой переменной не будет обращения с другого потока? Дайте угадаю - вы просто все продумали и пришли к выводу что эта ситуация невозможна? (т.е. по факту "мамой клянусь!") Но тут есть ваш коллега, у которого другое мнение на этот счет)) А потом Сaptain "That should never happen" strikes! Again... и у нас очередная уязвимость из-за гонки. > может и не готов для "повседневного" использования, но в принципе уже рабочий. Это немного не так. Но раз вы не в контексте, то нет смысла это обсуждать. Когда они его допилят, тогда вернемся к этой теме. > По вашей ссылке - пустота. По всем четырем?? Надо же. Вот тогда вам еще одна stackoverflow.com/questions/71010294/different-results-between-clang-gcc-and-msvc-for-templated-constructor-in-base-c Результат работы msvc отличается от gcc и clang. Получается вы берете рабочий код, компилируете под другую платформу и он начинает работать неправильно. Странно что вы не видите в этом проблемы. > У меня за плечами уже не одна сотня тысяч строк кода на С++ Вы же понимаете, что личный опыт так себе аргумент. > И речь опять таки изначально шла не про С, а про С++ - просьба не менять тему. Да, простите. С++ники тоже не сделали такой инструмент. Может потому что им нравится делать, а потом исправлять уязвимости (мозила и хром передают). А может потому что они не видят в этом проблемы. А может задача слишком сложная с теми вольностями что позволяют плюсы. Кто знает. > а запустить и посмотреть - где валится. И работать уже по месту. А валится оно где попало и в рандомных местах. Потому что память в этот момент уже испортил кто-то другой просто выйдя за границы буфера. И какую именно память он попортит в след. раз никто угадать не может. А еще это повторяется отнюдь не всегда. Ну удачи, расчехляйте санитайзеры. Несмотря на то что сейчас я не с++ программист, мне доводилось исправлять такие баги. И больше не хочется))
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 19:18 , 27-Мрт-24 (133)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 23:59 , 27-Мрт-24 (148) +1
Ворвусь как я в тред, если никто не против)> Если же конечный результат не соответствует ожиданиям - то это уже проблема конкретной реализации, а не стандарта. Т.е., иными словами - баг, или просто недоработка. Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не специфицирован" это баг, или просто недоработка? Я беру одинаковый код, но на разных компиляторах я получаю разный результат. Можно ли говорить о корректности кода и "стандартизованности" стандарта. > Программист для того и существует, чтобы тратить своё время именно на такие вещи. Но такие вещи как автоматизация позволяет тратить эти вещи на сложные задачи и не тратить на рутинные. Например автотесты или санитайзеры упрощают жизнь, ускоряют разработку и уменьшают шанс ошибится. > Всё куда проще. Я в своё время тоже напрыгался с подобными вещами. > А потом просто выработал для себя несколько простых правил, которые позволяют подобных ошибок избегать. В частности например, "пишешь delete - дважды проверь, что именно". Пока что работает. Судя по всему, у вас очень большой опыт разработки. Но, к сожалению вас нельзя клонировать, скопировать и тд. А для производства больших проектов нужны сотни таких как вы. > Иными словами, смысла в Rust нет никакого на мой взгляд, потому что всё, что преподносится, как его преимущество, в С++ достигается применением определённого стиля программирования. Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте вообще редкость). Я видел как люди уходили из открытых проектов просто по причине "я не хочу ждать пока на пулл реквесте пробегут автотесты! я же профи, ты что не доверяешь мне?!" > При этом всегда остаётся возможность поступить как-то иначе, если вдруг в этом возникнет необходимость. Как и в расте. Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу") > А какая собственно разница, что там в инструкциях программы? Меня интересует, сколько и на что будет потрачено тактов процессора. Всё. Остальное - значения не имеет никакого. Ну, меня тут еще интересуют другие вещи: среднее время работы до критичной ошибки, как быстро в коде разберется новый человек и тд. Возможно это связано с тем что я работал в больших проектах с немаленькими командами. > Нет, на такие вещи я не полагаюсь никогда. А вот на знание, как именно работает моя программа - да, полагаюсь. И не просто так, а протестировав предварительно все возможные варианты. Предположу, что в некоторых проектах это работает. Особенно если весь код написал сам. А в некоторых нет. Т.к ты можешь делать свой модуль, а в это время еще десять человек пилят пяток других. И ты их код увидешь или на код ревью, или когда полезешь там что-то исправлять. > В частности, я говорил, что если вы видите UB, то ничто вам не мешает его обойти. Гораздо хуже, когда программист не видит UB) Т.к запомнить все особенности всех компиляторов. Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда и приходите", но работает это плохо. > Ну и для избежания дальнейшего непонимания - резюмирую свою позицию. Rust - это по факту чуть более высокий вид абстракции, что на мой взгляд не нужно совершенно. В ядре я имею ввиду (с чего собственно весь разговор начался). Но к сожалению в ядре у нас, не современный С++, с умными указателями и прочими благами цивилизации, а С11, причем на него они перешли только ЕМНИП в 22году. > Для прикладных задач - да пожалуйста, пользуйтесь сколько угодно. Это ваше личное дело. Если получится что-то годное - лично я только за. К сожалению он для совсем прикладных приложение не очень подходит, тк UI на нем писать непросто. > Напрягает же что Rust пихают усиленно везде, где только можно и нельзя Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая) > хотя на поверку все его расписываемые достоинства оказываются не такими уж и достоинствами. Потому что всё это легко достигается в других ЯП просто применением соответствующего стиля программирования. ... для чего нужно воспитать целые поколения программистов, заставить их следовать стилю и надеяться что стиль подойдет под задачу. > А вот недостатки вполне просматриваются - например отсутствие стандартизации или явно бОльшее количество инструкций как на этапе компиляции, так и на этапе исполнения. По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции. Но на них почему-то перешли. Особенно если время компиляции стоит N денег, а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом N < M. > Пропихивание же говорит, что это кому-то надо. Зачем? Ну... Мы сегодня живём при капитализме. Пропихивают, значит кто-то увидел свой личный денежный интерес Напомню что СИ был разработан как потомок языка Би (который разработали AT&T, корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация) для абсолютно денежного интереса. И в этом (для меня) нет ничего плохого. Ада писалась по заказу Министерства обороны США. И плохим это ее не сделает А раст для меня похож на токарник с ЧПУ, он умеет часть вещей делать автоматически, но если нужно - можно управлять им в ручном режиме. И сейчас программист - это почти как слесарь или инжинер в 70-80 (куча народу работает над ) На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки, светофоры и даже ставят отбойники. А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью. Так что я за вещи, которые позволят сделать код надежнее.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 08:04 , 28-Мрт-24 (158)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:43 , 28-Мрт-24 (165)
> Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно.А вот и нет. Всё звучит логично если бы не маааленький нюанс: Eval order в стандарте undefined behavior только до C++17. https://en.cppreference.com/w/cpp/language/eval_order А потом ВНЕЗАПНО это поведение стандартизировали! Как же так получилось, что все предыдущие версии оно жило как UB, а потом вдруг это смогли пофиксить? Может это таки проблема в стандарте, а фича?)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 14:03 , 28-Мрт-24 (169)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:53 , 28-Мрт-24 (166)
> Тут не считать, а понимать надо, от чего именно так сделано.Понимание мне никак не поможет в случае "а в этом компиляторе разработчики захотели выпендрится" Придется читать доку на каждую версию каждого компилятора в надежде, что в мире есть хоть где-то стабильность. > Понимать, что такое ABI и конвенции вызовов. Иметь представление, что ... здесь с порядком возникают неоднозначности. > Отсюда следует вывод - в стандарте в этом случае поступили совершенно верно. Я об этом в курсе, но в примере с которого все началось, человек запускает один и тот же код, на одной машине с одним процессором. (stackoverflow.com/questions/5158014/why-do-different-c-compilers-give-different-results-for-this-code) И получает разный результат. Потому что создатели компилятор решили сделать по разному. Это говорит о том, что для того чтобы программа работала предсказуемо, нужно фиксировать тип компилятора и даже его версию. А ситуация "вот вам код, найдите именно GCC и версию компилятора 7.1.5 тк оно гарантировано работает только на нем" это просто дрмовая ситуация. Но вполне укладывается в Stable is nonsense идеологию. > А кто не знает, что такое конвенция вызовов - тому в ядре делать вообще-то и нечего. Сотня таких разнесут проект к чертям. И кто тогда будет писать ядро? Будем делать экзамен на проф пригодность? Попросим корпов нанимать только самых лучших, а что если они скажут 'неа, нам лучшие нужны себе'? А других программеров у тебя просто нет)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 14:26 , 28-Мрт-24 (170)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 13:46 , 28-Мрт-24 (167)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., C00l_ni66a, 16:47 , 27-Мрт-24 (108) [V]
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 17:54 , 27-Мрт-24 (124) +1
> А пока что этот кривой кусок ржавчины для чего-то серьёзного не годится.Спасибо C00l_ni66a! Ты открыл нам всем глаза! Не забудь написать Торвальдсу что-то вроде "Товарищ Линус, произошла чудовищная ошибка!" А то красношапка уже не этом кривом куске начала дрова писать для невидии)) > Потому что ЯП учить надо, а не раскидываться баззвордами. Потому чтj стандарт должен быть стандартом, а не куском "нуянеуверенсамиразберетесь" овна. > И если разрабы вдруг решат, что им срочно нужна телеметрия или платное DLC Мда... сходи к наркологу, что ли.... > тебе придётся смиренно кушать, что дают. Компилятор открыт под свободной лицензией MIT. Форкаешь компилятор и вперед. > Это называется "вендорлок", если ты вдруг не знал. Вендерлок - это огороженные гнутые экстеншены в ядре линукса. Чтобы не дай бог кто-то не скомпилил ядро другим компилятором. > поддерживающий аж полторы архитектуры Все архитектуры, которые поддерживает llvm > То самое, про которое все знают, но фиксить будут *потом*? Не, не смущает. Пофиксим сразу после того как сишники и плюсовики все UB уберут.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., C00l_ni66a, 19:10 , 27-Мрт-24 (131)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 19:22 , 27-Мрт-24 (134)
> Это скорее контр-пример, потому что ярко демонстрирует, кто и как обычно пытается пропихнуть ржавое поделие и кто с этим соглашается.В фантазиях таких фанатиков-параноиков как ты)) > ...инструкцией "как кaкaть" для самых маленьких. Ты либо конкретику вноси, либо прекращай газировать лужу. Конкретику? Да хотя бы определитесь как должен вести себя signed overflow. > Слив засчитан. Я не собираюсь обсуждать твой бред. Пиши конструктив, а свои маняфантазии засунь себе... куда подальше в общем. > В этом и суть вендорлока, *формально* ты можешь попытаться что-то сделать, но > на практике ты не вывезешь, потому что у твоих конкурентов есть > деньги, власть и неограниченное число кодеров, в отличии от. GCC контролируется корпами чуть больше чем полностью: gcc.gnu.org/steering.html Там одни корпы - IBM, Red Hat, SUSE, Google,... Вот что ты сделаешь, если они сделают вышеперечисленный тобой бред в след. версии компилятора GCC? А ничего, ты точно также утрешься как и с компилятором раста. Поэтому прекрати гнать дичЪ про вендорлок. > Ложь, LLVM сам по себе тут не причём. Хотя, даже при этом, > LLVM поддерживает действительно не так уж и много, в сравнении с тем-же GCC. Вам нужно старые маргинальные и некроархитектуры, которые тянет GCC - ВОТ САМИ И ПИШИТЕ)) Нам не нужно, Линуксу тоже. > О чём и речь, "потом". Твои набросы про UB никого не волнуют Вот когда пофиксят, тогда и предоставлю)) Твои набросы на раст тем более никого не волнуют. Ты мне напоминаешь Скалнета, только в контексте раста. Ты ходишь в каждую тему, cpешь и ноешь. Но твое нытье не изменит НИЧЕГО. Раст УЖЕ в ядре. Уже написаны дрова для видяхи М1, уже пишутся дрова для нвидии. И дальше будет больше))
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., C00l_ni66a, 20:25 , 27-Мрт-24 (139) –1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 21:30 , 27-Мрт-24 (143)
> я к стандартизации С++ отношения не имеюДа ты вообще ни к чему не имеешь отношения. И к ядру линукса тоже. > Тут только ты ходишь по комментариям и ноешь/набрасываешь про "дыpяшку" Напомню, что мы сейчас комментируем очередную новость про очередную дыряшечную CVE в ядре линукса с получением рута. Причем с рабочим прототипом эксплоита)) Потому что эти рукоопы дважды очистили память. Как и год назад. Как и два. Как и тридцать. Потому что дыряшечники как не умели в память, так и не умеют. Разве после такого вообще нужно набрасывать?? Но нет, конечно дыряшка не дыряшка, а погромисты не рукоопы! Это все набросы! И новость тоже врет! Боже, какой же ты клоун!)) > А я лишь подлавливаю тебя на лжи, маняпуляциях и пустом балабольстве, не более. Пока что ты меня еще ни на чем не подловил. Так что старайся лучше)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., C00l_ni66a, 15:04 , 29-Мрт-24 (173)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 15:59 , 29-Мрт-24 (175)
> Фанатик открывает тайну мироздания о том, что людям свойственно допускать ошибки. Фото в цвете.О, какой жижкий обсер /_- Если Человек Разумный пользуется интрументом, который создан так что позволяет допускать ошибки, что он делает? Он его улучшает! Так появляются кожухи на болгарке, изоляция клещей которыми лезут в электрощиток, для профи всякие изолирующие коврики. Для станков добавляют датчики отключающие его, когда в опасную зону заходит человек, а у преса появляются 2 кнопки которые нужно нажать одновременно (именно одновременно), дабы твою руку не отрезало. Что делают упоротые фанатики? Они отказываются от прогреса и совершают одни и те же ошибки и года в год. > Набрасывать вообще не нужно, но тебе это не мешает делать то под каждой новостью где хоть как-то упоминается си или хруст. Но это же весело! Во-первых можно тыкать носом любителей дыряшки в каку которую они написали. Во-вторых иногда в комментах бывают нормальные обсуждения каких-то сложных материй (но чаще конечно срч и оскорбления) > Конкретные погромисты мб и вполне себе рукопoпы. Если ты воспользуешься памятью или историей комментариев, то увидишь, что в прошлый раз я писал именно об этом, т.е. о том, что низкая квалификация конкретных лиц при использовании конкретной технологии - говорит в первую очередь об этих лицах, а не о технологии. Опять сам себя слил, подтвердив мой тезис, красава. Неа, у нас разное определение "низкой квалификации". У тебя - те кто не могут писать без ошибок. А у меня - те кто не могут найти инструмаен позволяющий писать без ошибок. Возьми условного рабочего и дай ему какой-то инстумент, например перфоратор, у которого нет двойной изоляции, или бур может вылететь из крепления кому-то в голову, или шестеренки открыты - то скорее всего тебе скажут "что за х!" и "не буду этим овном пользоваться". И это определит его квалификацию. Но для дыряшечников - это достоинство, можно же столько раз засверлиться себе в ногу)) Я уже насмотрелся на таких которые "не вижу проблемы делать пескоструйку без сиз", а потом "что-то дышать тяжко" > Странно, почему-то история комментариев говорит об обратном. За стандарт ты не пояснил; кучу съездов с темы не обосновал; в теме UB и IDB до сих пор не разобрался, но в этом треде уже накинул; А разве это "стандарт", если один и тот же код может работать по разному? Ну ладно, так и быть буду называть это "стандартом" > по топику вендорлока слился почти "всухую" (ну или "мокрую", если учитывать твоё измазывание); Лол, ты просто наложил кучу типа "если они завендорлочат, то мы сами не сможем". Так раст для гцц пишут, пока не готов, но если вдруг закончал, то как ты тогда будешь извиваться? Посмотри сколько было успешных форков. Один только ХОрг чего стоит. > это всё не учитывая множество других, более мелких обосрамсов, маняпуляций, софистики и прочих набросов. Ты опять проецируешь? Может тебе лучше стоит пойти штанишки сменить? > Прочный у тебя манямиpoк, однако, впрочем, на реальность никак не влияющий. Полность согласен. У тебя полное отрицание и проблем дыряшки, и того факта, что Раст уже в ядре и дальше будет больше. Некоторые успешные опенсорс компании - например Гугл, новый код андроида стараются писать исключительно на расте. И делают поблажки только для совсем древник кодов. Возможно через лет десять новые кода в ядре будут только на расте. И тогда от сишников модно будет избавиться) - Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., C00l_ni66a, 18:07 , 29-Мрт-24 (176)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 18:56 , 29-Мрт-24 (177)
> Инструмента, который *не позволяет* допускать ошибки - существовать не может, чисто концептуально. Но есть который позволяет их избегать) > И в хрустящем """софте""" встречаются всё те-же выходы за границы массива, переполнение сигнедов (тебе ссылку уже кидали, ага), но так как хрустяшку позиционируют как мегасафети - её адепты расслабляются и могут не заметить, что из-за ужасного дизайна язычка там может *случайно* протечь унсейф контекст в сейф через лямбды, например. О, ты ты наверное из тех кто "сгорел сарай, гори и хата". У гугла как-то получается уменьшить кол-во ошибок памяти при использовании раста, а у тебя нет. Даже удивительно! > И да, напомню, что аналогия - это НЕ аргумент. Естествено! © Но с тупенькими приходится применять аналогии, тк факты они не очень впоспринемают. А вот то что 1. раст приняли в ядро 2. на нем уже написали драйвер под м1 который прошел сертификацию 3. его внедряют в андроид и винду это говорит о том, что его преимущества работают. > Да, логичным итогом улучшения сишки стал C++. Который, в отличии от куска ржавчины, именно что решает проблемы, Хахаха, только оно не сработало. Приходится обмазываться санитайзерами, фаззингом. Дабе когда добавили МираклПТРы, то оказалось что оно жрет ресурсы, а выхлопа 50% > а не предлагает БДСМ-пати под предлогом мнимой бищапащности. Меня мало волнуют твои сексуальные фантазии, но осуждать тебя не буду) > Именно! Они отказываются принимать тот факт, что прогресс и его направление объективны, ввиду чего получают ржавую мазню, вместо вменяемых инструментов. Если для тебя прогресс это древние кривый инструменты от дидиов, то можешь ими пользоваться. Но не жалуйся если караван уйдет и ты останешь за бортом прогресса. > Не фантазируй, разработчики ведра вряд-ли сидят на опеннете. Думаешь в ядро так сложно сделать хотя бы один коммит? На самом деле нет. > Демагогию не разводи. Если вдруг забыл - иди перечитывай, либо приводи конкретные аргументы, а не в очередной раз газируй лужу. Кажется у тебя просто шизофрения /_- Аргумент: написанный код должен одинаково работать на одной и той же платформе. Если это не так - это баг. >>Лол, ты просто наложил кучу > Проекция. Аргументы в стиле "нет ты"? Значит аргументы закончились) > Кто "мы" и с чего-бы? Фантазируешь. Аргументация была иная, перечитывай иди, демагог. Опять обосратушки? Ты там штанишки почаще меняй. > Вот когда будет готов - тогда и приходите. А я говорю про положение дел *сейчас*, а не когда-то там в будущем, которое легко может ещё и не наступить. Положение дел сейчас - рас добавили а в ядро, растохейтеры идут на Хурд. > Посмотри, сколько было успешных форков проектов, по размерам и комплексности сопоставимым с компилятором хруста. Опять маняпулируешь, уже не интересно. Какой же ты тупой... Я тебе привел форк xfree86, который сейчас используется на половине десктопных линуксов в виде ХОрга. Хочень сказать что реализация Х11 это проще чем компилятор? > Тогда зачем ты его сюда публикуешь? Любишь золотой дождь? О... ты опять начинаешь свои половые фантазии. Ну зачем? Мне ж оно не интересно. > Ты пока что ни разу не указал на "проблемы дыряшки", всё что ты тут намазал - это фантазёрство и баззворды про "ужасный UB" без толики конкретики. То что стабильно раз в пару недель читаем "уязвимость из-за UB которая позволяет получать рут". Для умственно отсталых это конечно не проблема. > "Опенсорс-компания" это только в пределах твоего манямирка. В реальности у гугла огромное число проектов имеют закрытые исходники. И? я что привел в пример проект с закрытым кодом? Хватит обделываться на ровном месте! У IBM тоже есть закрытые проекты, но это не уменьшает их заслуг в опенсорс проектах. - Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., C00l_ni66a, 16:07 , 30-Мрт-24 (185)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:22 , 27-Мрт-24 (70) –1
Что значит неправильно использовать? Использовать так, как уместно в конкретном случае. Да, это вам не растофашизм.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:30 , 27-Мрт-24 (74) +1
> Использовать так, как уместно в конкретном случае.Вот погромист из этой новости посчитал, что вполне уместно в том конкретном случае очистить память дважды. Почему? А потому что ему так захотелось. И в с++ можно сделать тоже самое. Никто же не запретит. Это вам не растофашизм))
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:29 , 27-Мрт-24 (95) –1
Раст ему никак не помешает сделать таких же unsafe глупостей. Без unsafe растовикр писать пока что не научились.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:32 , 27-Мрт-24 (100) +1
За unsafe тебя спросят на первом же кодревью. Ты можешь пройтись поиском и легко найти все места где есть unsafe. Это тебе сократит область поиска в десятки раз.> Без unsafe растовикр писать пока что не научились. Есть целая категория либ unsafe forbidden, где его вообще запрещено использовать. Как же интересно они их написали?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:25 , 27-Мрт-24 (92)
> но до раста ему топать и топатьПочему вы все тогда компиляете свой расто-код компилятором, написанным на C++?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Пряник, 14:16 , 27-Мрт-24 (68)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:20 , 27-Мрт-24 (69)
Плюсы сложнее сишки во всём, с чего это они должны быть в ядре? Лучше уж сишка, хоть и старьё.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 14:30 , 27-Мрт-24 (75) +1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:03 , 27-Мрт-24 (85)
> это всё относительные понятия. Т.е. при их употреблении нужно сразу уточнять - для кого?Именно! Не думал что скажу это, но согласен. Напрмер Раст - он 'проще' для тех кто не сильно знаком с СИ или плюсами, и 'сложнее' для Сишников. Он 'легче' в том смысле что у него меньше UB/IB и тд, но 'тяжелее' в том что нужно освоить новые концепции типа borrow. Он 'лучше' для кода, тк практически убирает ошибки памяти и дает программерам возможность сосредоточиться на например логических, но при этом он убирает возможность сидеть на поддержке СИшного овнокода десятилетиями, и для программистов это 'хуже' тк согласно религии секты бородатой антилопы, зарабатывать деньги можно только на поддержке кода. > Возраст языка программирования тоже не играет вообще никакой роли. Имеют значения лишь его технические особенности. А вот тут не соглашусь. Старые языки содержат в себе концепты и подходы своего времени. И обычно приходится тянуть обратную совместимость, что не позволяет выкинуть весь старый хлам и добавить новые подходы. Например создать класс Error и перестать прокидывать результат функции/ошибки интами.(положильными результат, отрицательными ошибки.. или наоборот? и не дай бор получить переполнение и сменить знак!). Или добавить pattern matching. А если авторы таки решаются поломать совместимость, то это происходит ну очень болезнено и с кучей проблем.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 16:23 , 27-Мрт-24 (91)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:53 , 27-Мрт-24 (110)
> Извините, но чушь. Не валите всё в одну кучу. Зарабатывание денег можно обсудить в другой плоскости, и Rust снова проиграет, но уже совершенно по другим причинам. Ладно, давайте отложим тему денег, предположим что у нас есть заадча написать какой-то код, для простоты пусть это будет либа. Она будет работать на миллионах устройств и поэтому для нее есть требования "максимальной надежности". Какой язык программирования вы бы выбрали? > Ну так всё описанное и есть технические особенности. Возраст тут совершенно ни при чём.
Странное утверждение. Это как говорить что "старые люди, обычно двигаются тяжелее, их реакции более замедленные, а имунная система менее активная не из-за возрачта, а просто у них такие тхенические особенности". Ведь для языков программирования эти технические особенности практически прямое следствие от возраста.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:04 , 27-Мрт-24 (86)
Технические особенности плюсов таковы, что язык не востребован за пределами геймдева. И дальше дискуссию можно не продолжать.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., ProfessorNavigator, 16:13 , 27-Мрт-24 (87)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:21 , 27-Мрт-24 (90) +1
Технические особенности сишки таковы, что на ней: - или тянут древние проекты вроде ядра линукса, которым десятилетия. - или используют для лютой ембедщины.Потому что плюс для прикладного программирования лучше сишки во всем. Особенно последние редакции от с++17 и выше. А сишка вообще остановилась в развитии.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:38 , 27-Мрт-24 (103) +1
Хмм.. а на чем там у соседей написан оффтопик? Удивительно, но их графическая система написана таки на с++.Самый популярный в мире браузер (и по совместительству самое популятное DE для ядра линукс) - chromium тоже написан на плюсах. Я могу еще вспомнить фотошоп, но тк тут форум любителей полуфа/bрикатов, то скажу что гимп частично написан на плюсах. А еще есть Open/LibreOffice, WxWidgets, 7-Zip и даже Haiku. Тысячи их!
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., n00by, 19:23 , 27-Мрт-24 (136)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Карлос Сношайтилис, 23:41 , 29-Мрт-24 (179)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Пряник, 14:25 , 27-Мрт-24 (71)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:53 , 27-Мрт-24 (41)
C ksmbd даже не удивлен. По дырам там поле не паханое.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 12:57 , 27-Мрт-24 (42) [V]
А ведь этой ошибки можно было избежать, использовав язык V.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., вася, 13:04 , 27-Мрт-24 (48) +1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:12 , 27-Мрт-24 (53)
Логично предположить, ответить на этот вопрос может исключительно производитель xiaomi redmi 8...
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., сщта, 13:15 , 27-Мрт-24 (54)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:20 , 27-Мрт-24 (55)
Дольше, чем для PinePhone.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 13:39 , 27-Мрт-24 (58)
> Сколько придется ждать, когда это исправление появится в моём xiaomi redmi 8? На redmi 8 ставится Lineage OS 21 (Android 14). Используется ядро 4.19. Получается как только бекпортнут фикс в 4.19 и линейка обновится. Не такой уж плохой расклад.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:33 , 27-Мрт-24 (77)
Авось, повезёт когда-либо и твой Xiaomi Redmi 8 появится в PostmarketOS. Вот тогда и будет исправление.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., bOOster, 14:02 , 27-Мрт-24 (62)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:09 , 27-Мрт-24 (63) +1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Tron is Whistling, 14:10 , 27-Мрт-24 (65) +1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 02:36 , 29-Мрт-24 (172)
Точно. Главное, чтобы в Линуксе было хуже, чем в БСД. Остальное неважно.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 14:31 , 27-Мрт-24 (76)
Проблема кроется в ахитектуре команд процессора. Изначально никто не думал о многопользовательской системе.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:29 , 27-Мрт-24 (97)
Всё подумали что это будет очень медленно и это так и есть.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:31 , 27-Мрт-24 (99) –2
Надо на RISC-V переходить.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 17:06 , 27-Мрт-24 (114) +4
слишком большой риск, практически пятикратный
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 07:47 , 28-Мрт-24 (157)
В общем-то поможет, если код nftables вырезать из ядра и крутить в отдельной аппаратной виртуалке. Но... приходим к гибридной архитектуре ядра тогда, как минимум.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 07:36 , 28-Мрт-24 (154)
В 80386 уже всё было для многопользованности. Проблема в том, что nftables тоже выполняется в кольце с максимальными привилегиями.
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., аНОНИМ, 15:11 , 27-Мрт-24 (81)
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 16:01 , 27-Мрт-24 (84)
Кто-нибудь вообще nftables начал использовать?
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Syndrome, 16:43 , 27-Мрт-24 (106) +1
- Уязвимости в ядре Linux, позволяющие поднять свои привилегии..., Аноним, 19:28 , 27-Мрт-24 (137) –2
Да, SMB и в винде себя хорошо показал на примере eternalblue, и того, что конфикер юзал.
|