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

"Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из состава ядра Linux"	+/–
Сообщение от opennews (??), 16-Окт-23, 11:31
В Linux-подсистеме nvmet-tcp (NVMe-oF/TCP), позволяющей обращаться к NVMe-накопителям по сети (NVM Express over Fabrics), используя протокол TCP, выявлена уязвимость (CVE-2023-5178), потенциально позволяющая удалённо выполнить свой код на уровне ядра или, при наличии локального доступа, поднять свои привилегии в системе. Исправление пока доступно в виде патча. Проблема проявляется с самой первой версии драйвера NVMe-oF/TCP (в отчёте об уязвимости упоминается ядро Linux 5.15, но поддержка  NVMe-oF/TCP была добавлена в ядро 5.0). Уязвимости подвержены систем с включённым сервером... Подробнее: https://www.opennet.me/opennews/art.shtml?num=59940
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
Сообщение от Аноним (1), 16-Окт-23, 11:31
освободил память? - присвой указателю нулл
Ответить | Правка | Наверх | Cообщить модератору

	2. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+10 +/–
	Сообщение от morphe (?), 16-Окт-23, 11:33
	Используешь C? - перестань
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+5 +/–
	Сообщение от EULA (?), 16-Окт-23, 11:37
	Переходи на С++?
	Ответить | Правка | Наверх | Cообщить модератору

	10. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от Анонин (?), 16-Окт-23, 11:55
	Хотя бы. Уже станет лучше. Но только если на современные плюсы, а не на сишку с классами.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+6 +/–
	Сообщение от morphe (?), 16-Окт-23, 12:05
	В плюсах при низкоуровневой разработке способов прострелить себе колено пожалуй даже больше чем в C
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от Аноним (15), 16-Окт-23, 12:14
	т.е мы приходим к теореме г-на Эскобара? Что С плохо (как видим из новости), что С++ не лучше. Вот бы придумали способ находить, а лучше предотвращать такие ошибки заранее, может какой-то новый язык написали) Хотя тут ИМХО даже стат анализатор помог бы, но кто его запускать будет, это же долго.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 16-Окт-23, 17:15
	Такие ошибки предотвращать относительно просто, это указатели с экслюзивным владением и счётчики ссылок. Автор модуля банально не осилил сделать корректное управление указателем, здесь нет никакой сложной низкоуровщены. В этой же дичи всё ещё goto используют. Если в этот долбанутый Си добавили хотя бы RAII, и научили несчастных им пользоваться, то значительной части уязвимостей просто бы не было.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от Аноним (15), 16-Окт-23, 18:06
	Так каждый раз когда приходит кто-то с предложениями улучшить процессы (я уже молчу про большие изменения, вроде 'добавить Раст') типа "а давайте сделаем стат. анадизатор обязательным, или добавим линтер", то начинается нытье "будет медленно, не хочу ждать 10 минут пока тесты пробегут" в перемежку с пафосными рассуждениями об ылитных пограммитах который этот код наделали, что ядро пишут только профи, которым это не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	–1 +/–
	Сообщение от Аноним (132), 16-Окт-23, 23:22
	Ядро с сопредельным софтом сначала придётся переписать полностью. Для смены языка.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (15), 17-Окт-23, 10:52
	Для смены языка - да. Это очень сложный путь. А обязательные стат. анализаторы? Ты думаешь, что их добавление приведет к нерешаемым проблемам? Да, наверное придется месяц-два потратить на исправление всех проблем, но лучше это чем такие уязвимости.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от bOOster (ok), 19-Окт-23, 07:38
	Очередной раз придурки не знают что такое Компоновщик/Линковщик?
	Ответить | Правка | К родителю #132 | Наверх | Cообщить модератору

	133. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от fidoman (ok), 16-Окт-23, 23:51
	уж вы-то лучше всех бы накодировали, без единой ошибки
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	122. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	–1 +/–
	Сообщение от анон (?), 16-Окт-23, 20:07
	На ночь через крон ставить не?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	47. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+1 +/–
	Сообщение от EULA (?), 16-Окт-23, 13:09
	> В плюсах при низкоуровневой разработке способов прострелить себе колено пожалуй даже больше > чем в C Чтобы не прострелить себе ногу достаточно не направлять на нее ружье, не? ===================== Учитель, почему, когда я делаю так int *a; a = new int; char *b; *a=1000; b=a; *b='0'; cout<< 1000/a <<"\n"; Получается фигня? - Не делай так!
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	148. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от name (??), 17-Окт-23, 15:02
	а это точно соберётся? там присвоение немного неодинаковых типов может вывести компилятор из себя
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от EULA (?), 18-Окт-23, 05:40
	> а это точно соберётся? там присвоение немного неодинаковых типов может вывести компилятор > из себя Код в таком виде большинство компиляторов откажется собирать. Но мысль, как и можно с указателями намудрить так, чтобы программа таки работала все, а по факту был идиотский результат, хватит.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Советский инженер (ok), 16-Окт-23, 14:58
	ето потому что к malloc/free добавили еще new/delete или что?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	82. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (82), 16-Окт-23, 16:08
	> В плюсах при низкоуровневой разработке способов прострелить себе колено пожалуй даже больше чем в C Хоть один пример приведете?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	83. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (82), 16-Окт-23, 16:15
	> Но только если на современные плюсы, а не на сишку с классами. Да даже если и на сишку с классам: наличие RAII уже само по себе избавило бы от этого убогого цирка с ручным управлением ресурсами и соответствующих CVE.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	156. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от morphe (?), 17-Окт-23, 22:20
	RAII уже включили в ядро... В Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (171), 20-Окт-23, 14:55
	> Да даже если и на сишку с классам: наличие RAII уже само по себе избавило бы от этого убогого цирка с ручным управлением ресурсами и соответствующих CVE. Не избавило бы. Сишникам только дай волю, они сразу полезут делать malloc'и и хранить строки в char*. У них квадратно-гнездовое мышление, переучить очень сложно. Типа "я 30 лет так делал и менять свои привычки не собираюсь, компилятор подвинься". Ну а потом естественно всё это феерично взрывается. Комитету C++ нужно отправить весь этот сишный треш в утиль.
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	137. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от penetrator (?), 17-Окт-23, 08:13
	если не с классами то с чем?
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	4. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	–1 +/–
	Сообщение от svsd_val (ok), 16-Окт-23, 11:38
	Используешь не С - перестань, с чего это такие глупые призывы. ХОТЯ ДА, нынче если Ваше ПО не жрёт фигову тучу ресурсов - это не гууд... нужно по 2-3гб и по 100% нагрузке на проц на всякую бессмыслицу что бы быть в тренде ... так получается ?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	9. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+7 +/–
	Сообщение от Аноним (9), 16-Окт-23, 11:51
	> нужно по 2-3гб и по 100% нагрузке на проц на всякую бессмыслицу Нет чувак. Это даже не проблема языка программирования, а лично разраба.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	–1 +/–
	Сообщение от svsd_val (ok), 16-Окт-23, 16:21
	Согласен, но ... только при одних и тех же обстоятельствах производительность и потребление ресурсов у разных языков разное. И как бы ты не старался для оптимизации работы некоторые вещи лучше писать на асме.... увы знаю о чём говорю... и Си и С++ в этом плане шибко проигрывают чистой асме. Не говоря о том что многие разрабы в место того что бы реализовать маленькую фигню самим тащат монструозные зависимости которые ничего не делают, жрут ресурсы и весят балластом ) Так что да у многих прогеров нынче с этим беда...
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	–1 +/–
	Сообщение от Анонин (?), 16-Окт-23, 20:19
	> Си и С++ в этом плане шибко проигрывают чистой асме Вот только сколько такого "горячего" кода в приложении? 20%? 10%? Еще меньше? Предварительная оптимизация - это зло. А пару маленьких кусков можно и на асме переписать потом, когда уже будут результаты работы профайлера.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от svsd_val (ok), 17-Окт-23, 18:37
	> Вот только сколько такого "горячего" кода в приложении? 20%? 10%? Еще меньше? Да, всё зависит от конкретных задач и конкретного приложения, тупейший пример: рендеринг, расчёт физики и т.п. (там где много ветвлений и циклов) производительность будет падать в разы а не каких то 10/20%. А теперь что касается реальных задач и конкретной темы в ядре падение скорости даже 2-3% уже сказывается на работу всего софта который был затронут зависимостями... там эти 2-3% могут как снежный ком расти... и в итоге ты будешь к примеру играть не 60fps а 45-48 потому что в коде оказался код который "тормозит" на 2-3%. вот это круто да.... понимаю всего 2-3% а не 10 и не 20%... > Предварительная оптимизация - это зло. Конечно, легче говно код написать и сказать что сейчас делать софт можно и нужно который и озу и проц жрут из расчёта что "У ВСЕХ ЕСТЬ ВОЗМОЖНОСТЬ КУПИТЬ НОВЫЙ КОМ" или новый сервер.... %) > А пару маленьких кусков можно и на асме переписать потом, когда уже > будут результаты работы профайлера. Вообще согласен, но иногда это код гораздо легче переписать с нуля чем исправлять и оптимизировать уже существующий ... p.s. Можете кидаться какахами но увы... % на % и на % уже водном месте , в другом в и в третьем ... они же зачастую суммируются... У народа тормозит, не справляется, не хватает мощи - не твои проблемы проблемы клиента, не оптимизируй код, пусть лучше он купит новое железо или добавит ещё пару пару десятков гб озу )))... Увы но Я в корпоративной среде много такого кода видел из этого расчёта написанного ))), да можно работать но иногда просто офигиваешь от того что не шибко сложные вещи могут давать такие нагрузки.... мб просто я уже старый пердун, но в МОЁ ВРЕМЯ все старались писать оптимизированный код сразу а не после того как жаренный петух клюнет...
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Анонин (?), 18-Окт-23, 21:49
	> легче говно код написать прикольно ты в противовес супер-оптимизированному асму ставишь сразу говнокод)) т.е. есть только черное и белое? не пишешь на асме - сразу говнокод?) современные компиляторы прекрасно оптимизируют код, при этом нужно тратить время на те места, где компилятор не справился > я уже старый пердун, но в МОЁ ВРЕМЯ возможно в то время средний погромист был умнее компилятора но увы, те времена прошли, и слава богу)) > все старались писать оптимизированный код сразу Похвально, вот только сколько времени ты будешь писать оптимизированный код на асме? Пока ты будешь это делать, Вася на си уже напишет не такой оптимальный и он уже будет решать задачу. Потому Васю попросят (или не попросят) ускорить свой код, а твой.. ну, останется у тебя.
	Ответить | Правка | Наверх | Cообщить модератору

	166. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от svsd_val (ok), 19-Окт-23, 16:40
	> прикольно ты в противовес супер-оптимизированному асму ставишь сразу говнокод)) Эм, похоже у кого-то с логикой не всё хорошо и делает выводы из своих же фактов ? Я утрировал и речь шла о том что предварительная оптимизация зачастую плюс, или ты собираешься пузырьковым методом сортировать массивы ? > современные компиляторы прекрасно оптимизируют код, при этом нужно тратить время на те > места, где компилятор не справился Да, но даже они проигрывают в рациональности и пониманию целей и оптимизации человека. > возможно в то время средний погромист был умнее компилятора > но увы, те времена прошли, и слава богу)) Через чур уверенное заявление ... > Похвально, вот только сколько времени ты будешь писать оптимизированный код на асме? И так я буду писать на 10-30% дольше, в зависимости от задачи, так как есть понимание где и какой подход в каких обстоятельствах лучше использовать. Далее, речь шла не только об асме (чего до него докопались то ?) но и о простых оптимизациях в коде, брутфорс наше всё и конечно он хорошо справляется, маленький легко понятный код ))).... На примере строки, как ты будешь производить поиск в огромном объёме ? На удивление простой перебор циклом не очень хорошая идея ))) > Пока ты будешь это делать, Вася на си уже напишет не такой > оптимальный и он уже будет решать задачу. Пока у Васи код будет выполняться 10 часов мой выполнится за 10 минут. Пока это разовое задача/действие - да подход Васи предпочтителен, но стоит запустить его больше раз... Хотя мб в этом и цель, что бы оправдания найти или выполнять одну и туже работу дважды ? > Потому Васю попросят (или не попросят) ускорить свой код, а твой.. ну, > останется у тебя. Если Вася не умеет писать более менее оптимальный код и не может структурировать его в голове, то и оптимизация у него будет на уровне ...
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+1 +/–
	Сообщение от An (??), 16-Окт-23, 11:51
	Того, что сказано выше - достаточно.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	17. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Анонин (?), 16-Окт-23, 12:18
	Осталось всего-лишь как-то заставить всех выполнять выполнять это элементарное действие. Всего-лишь...
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от An (??), 16-Окт-23, 12:42
	А еще - программы надо проектировать. Тогда и на си можно будет норм. писать(и даже без зануления указателей). Везде так, сначала проектируют, потом реализовывают и только в программировании "самодокументируемый код".
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 14:17
	А как вообще можно проэктирвоать архитектуру опенсорса? Без шуток, я понимаю как оно делается в проприетарных проектах, но в распределнном проекте на тысячи человек. Ну т.е даже если есть архитектор который придумал как оно должно быть и как нужно реализовывать. А потом приходит кто-то с уже готовым кодом, который... ну не влазит в архитектуру. И есть выбор: попросить переделать или ждать пока кто-то другой реализует, но это может быть долго. (а может и никогда) Может кто-то сталкивался как решают такие диллемы?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (1), 16-Окт-23, 14:55
	тысячи человек, приходит с кодом.. ну ты и фантазёр (тут я не шучу, ты явно никогда в ОС движении не был) - почему-то вспоминаются постановочные скриншоты слака: - Кто может взять этот баг? - Конечно я!
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 15:13
	> ты явно никогда в ОС движении не был Конечно не был, поэтому и спрашиваю) Просто пример ехФАТ дров - был драйвер самсунг, но он был устаревший и требовал допиливания (насколь понимаю сама самсунг на него уже давно забила). И тут приходит Paragon и приносит на блюдечке драйвер. Как согласовывали требования к драйверу и что бы было если бы они на них забили, но драйвер все равно работает. Взяли бы его в ядро или нет?
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (1), 16-Окт-23, 15:24
	эти люди делают это за деньги - они сразу знают как, в "эти люди" включены и менеджеры, которые знают о рисках.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Анонин (?), 16-Окт-23, 15:26
	Ну почему сразу постановочные? У меня такое было и не раз. Смотришь в борду - а там все такое унылое и муторное... а тут кто-то находит интересную критику! И да, пишу, что с удовольствием займусь этим багом))
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	127. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (82), 16-Окт-23, 22:05
	> А еще - программы надо проектировать. Тогда и на си можно будет норм. писать(и даже без зануления указателей). Не смешите... Сишные кудесники, бедненькие, в одной функции запутались: то память дважды освободят, то за пределы буфера вылезут - а вы им проектирование хотите поручить? Бракоделам, которые без goto и сотни строк не в состоянии написать?
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	24. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (24), 16-Окт-23, 12:39
	Ну и будет локальный указатель внутри функции указывать на NULL, ок. А тысячи других указателей, которые не в курсе, что ты один локальный указатель обнулил, что делать будут? Или ты предлагаешь всё переписать на двойной указатель или вообще не безопасТный язык?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	67. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+1 +/–
	Сообщение от Аноним (1), 16-Окт-23, 15:01
	уязвимость в новости - дабл фри
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (96), 16-Окт-23, 17:09
	> тысячи других указателей Если ты присвоил один и тот же указатель тысяче разных мест, а затем без всякой координации освобождаешь в каком-то одном месте, а затем получаешь double-free, то это в первую очередь характеризует тебя. Как человека, которого к сям подпускать нельзя. (ЧСХ, именно такие на сях и пишут.)
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	50. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от Аноним (96), 16-Окт-23, 13:14
	Среди сишников бытует мнение, что "ptr = NULL" — это очень долгая операция, и нужно экономить такты.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	78. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Аноним (24), 16-Окт-23, 15:58
	Ничего тут не медленно, просто бесполезно, потому что это никак не влияет на другие указатели.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от Аноним (96), 16-Окт-23, 17:05
	чувак, если у тебя один и тот же кусок памяти используется многими структурами, следует наконец ввести ref/unref или прочие техники управления памятью. Указатели у него, видите ли, "не влияются". Твоя претензия смехотворна, ибо double-free возникает при НЕиспользовании техник типа подсчета ссылок -- то есть как раз там, где такие техники и не нужны, ибо памятью владеет кто-то один. Кто-то один, кто забыл обнулить единственный указатель на память.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+3 +/–
	Сообщение от Аноним (100), 16-Окт-23, 17:41
	Не нужон нам ваш ref/unref.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Tron is Whistling (?), 16-Окт-23, 15:21
	Какому именно указателю? Их может быть несколько в совершенно разных структурах.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	74. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+2 +/–
	Сообщение от Аноним (96), 16-Окт-23, 15:39
	А, ну да, тогда никак. Придется дважды освобождать память. А иногда и десятижды. ^ ты же к этому выводу всех склоняешь?
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Удалённо эксплуатируемая язвимость в драйвере NVMe-oF/TCP из..."	+/–
	Сообщение от Tron is Whistling (?), 16-Окт-23, 20:51
	Склоняю к тому, что use-after-free и double free возникают по другим причинам. Можно занулить _свой_ указатель - но надо ещё убедиться, что другие структуры уничтожены либо сделаны то же самое. То есть просто зануление не спасёт.
	Ответить | Правка | Наверх | Cообщить модератору

5. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+4 +/–
Сообщение от Анонин (?), 16-Окт-23, 11:44
Haha, classic. "Прошло 5 дней с последней сишной дырени"
Ответить | Правка | Наверх | Cообщить модератору

6. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
Сообщение от ryoken (ok), 16-Окт-23, 11:46
Подскажите, с целью повышения уровня образованности. А какой "use case" у этой технологии? Уже есть сети, быстрее оперативы? Честно, не троллю, хотелось бы получше разобраться.
Ответить | Правка | Наверх | Cообщить модератору

	7. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Анонин (?), 16-Окт-23, 11:51
	> Уже есть сети, быстрее оперативы Нет. Просто в оперативу всё не влазит(( Даже в стойку нужное кол-во nмme не влазит. Приходится ставить рядом еще одну, читать оттуда и терпеть просадки по перформансу. Вот такая вот печалька. Но что поделать.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 16-Окт-23, 17:44
	Тогда нужен RDMA, а не поделие из топика
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от edo (ok), 19-Окт-23, 22:07
	RDMA сам по себе не решает проблему доступа к удалённому блочному устройству. А оффлоады nvmeo* уже есть в сетевых картах, кстати
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от wWolf (?), 16-Окт-23, 11:58
	Да. https://ru.wikipedia.org/wiki/DDR_SDRAM#%D0%A1... https://en.wikipedia.org/wiki/Fibre_Channel#History
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	13. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от voiceofreason (?), 16-Окт-23, 12:06
	SSD уже догнали ддр4?
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Анонимусс (?), 16-Окт-23, 12:11
	Ты в пример привел какое-то старье. Даже у уже устаревшей DDR4-2400 - bandwidth 19200 MB/s. А у DDR5 - 38400 для стандартной 4800 и 57600 для 7200. А у фибры - максимум 25600 MB/s, и то - только на самой распоследней.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	152. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (152), 17-Окт-23, 21:24
	Оптика уже 600 гигабит умеет. Ну нафиг ненужно распределенную базу данных при распределенных вычислениях гонять через цпу который офигеет. Не просто же так начали жпу натаскивать на чтение из накопителя напрямую. Это даже при локальном использовании желательно.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от space (?), 22-Окт-23, 14:55
	Подскажите лучше, как контролировать все что работает на gpu, а то проц молчит, а gpu дает доступ ко всему что на компе без вашего согласия :)
	Ответить | Правка | Наверх | Cообщить модератору

	16. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (16), 16-Окт-23, 12:16
	Как более современная замена iSCSI.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	21. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от OpenEcho (?), 16-Окт-23, 12:29
	> Подскажите, с целью повышения уровня образованности. А какой "use case" у этой технологии? Это тоже самое что и iSCSCI, только позволяющее гигантские очереди и пути, и как результат увеличение пропускной способности и уменьшение задержек и при всем этом не надо какого-то специфического железа
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	34. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хохлоним (?), 16-Окт-23, 12:47
	https://gist.github.com/jigi-33/5cca0dac52da6a39a63d9546fb69... На транспортном уровне расположились TCP -- протокол, обеспечивающий передачу данных с гарантией доставки, и UDP -- протокол для быстрой передачи данных, но уже без гарантии. https://proglib.io/p/computer-networking Протокол управления передачей (англ. TCP - Transmission Control Protocol) обеспечивает надежную доставку данных. Сервис TCP так и называется: reliable byte stream (надежная передача потока байт). Этот протокол отвечает за доставку данных и сохранение порядка передаваемых сообщений. ... Разбираемся с HTTP ... Он использует протокол TCP и порт сервера 80 (для клиента порт генерируется операционной системой).
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	40. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хохлоним (?), 16-Окт-23, 12:58
	И вот в итоге: https://hwp.ru/articles/chto_takoe_nvme_of_i_kak_rabotaet_sa... Чтобы полностью реализовать потенциал твердотельных накопителей, нам нужна технология, которая сможет осуществлять обмен данными на более высокой скорости. NVMe — вот та спецификация, которая позволяет твердотельным накопителям реализовать потенциал флэш-памяти. Эта технология была представлена в 2014 г, и её основными задачами стали повышение скорости работы приложений (сокращение времени отклика) и внедрение новых и улучшенных возможностей. Существует множество форм-факторов твердотельных накопителей на базе NVMe, и наиболее известные — это AIC (карта расширения), U.2, U.3 и M.2. Твердотельный накопитель на базе NVMe соединяется с компьютером или сервером посредством высокоскоростной шины Peripheral Component Interconnector Express (PCIe), к которой он подключается напрямую. NVMe снижает дополнительную работу центрального процессора и сокращает время между операциями, увеличивая количество операций ввода-вывода в секунду и пропускную способность. К примеру, NVMe SSD предлагает скорость записи свыше 3000 МБ/с, что в 5 раз выше в сравнении с твердотельным накопителем, оборудованным интерфейсом SATA, это в 5 раз выше и в 30 раз выше по сравнению с жестким диском. NVMe поддерживает множество операций ввода-вывода (!), выполняемых одновременно, это означает, что масштабные задачи могут быть разбиты на более мелкие, которые будут обрабатываться независимо друг от друга. Это чем-то напоминает работу многоядерного процессора, который обрабатывает несколько потоков команд одновременно. Каждое ядро процессора может работать независимо от других ядер и решать индивидуальные задачи. ... На SATA так не сделаешь
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от edo (ok), 19-Окт-23, 22:18
	Очереди и в sata есть, гораздо более жиденькие, конечно, но для большинства задач достаточные
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хохлоним (?), 16-Окт-23, 13:06
	https://nvme.smb-solution.ru/nvme-tcp/ Редакция спецификации NVMe-oF 1.1, включает поддержку транспортной привязки TCP. Добавление NVMe поверх TCP (NVMe/TCP) позволяет использовать NVMe-oF в стандартной сети Ethernet. Отпадает необходимость изменения конфигурации или использования специального оборудования. Транспортная привязка TCP в NVMe-oF определяет методологию, используемую для инкапсуляции и доставки данных между хостом и подсистемой NVMe. Cпецификация NVMe/TCP ориентирована, главным образом, на программные реализации, использующие интерфейсы приложений TCP. Но спецификация не исключает использование NVMe/TCP для аппаратных реализаций. ... Поставщики готовы к NVMe/TCP Производители готовы поставлять компоненты и решения на базе NVMe/TCP. — Упоминавшаяся уже Chelsio Communications предлагает сетевые адаптеры на скорости до 100 Гб/с. — Mellanox в пресс-релизе указал на совместимость с NVMe/TCP сетевых адаптеров и коммутаторов, работающих на скоростях до 200 Гб/с. Теперь сетевые адаптеры ConnectX Mellanox одновременно поддерживают оба протокола NVMe-oF — и TCP и RoCE. Это позволяет внедрять NVMe платформы, работающие по TCP и RoCE. Ряд поставщиков уже предлагает решения на NVMe/TCP в своих предложениях. В частности, LightbitsLabs.com и Solarflare Communications Inc. — Платформа хранения Lightbits включает NVMe/TCP в составное блочное хранилище, которое может быть реализовано без ущерба для сетевой инфраструктуры или клиентов центра обработки данных. — Solarflare также предлагает композитное хранилище на основе NVMe/TCP. Оно позволяет центрам обработки данных использовать существующие сетевые инфраструктуры. Поставщик работает с SuperMicro Computer Inc. В решениях используются системы Supermicro Ultra SuperServer и TCP-оптимизированные сетевые карты Solarflare.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	56. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хохлоним (?), 16-Окт-23, 13:52
	https://www.kingston.com/ru/ssd/what-is-nvme-ssd-technology По поводу железа: Технология NVMe обеспечивает превосходное хранение данных, превосходную скорость и превосходную совместимость. Поскольку в технологии NVMe используются разъемы PCIe, она обеспечивает передачу в 25 раз большего объема данных по сравнению с аналогичными устройствами SATA. Наряду с большим объемом данных команды NVMe выполняются в 2 раза быстрее, чем в накопителях AHCI. Кроме того, количество операций ввода-вывода в секунду (IOPS) в устройствах NVMe превышает 1 миллион, и операции выполняются до 900% быстрее по сравнению с накопителями AHCI. NVMe также напрямую связывается с ЦП системы, обеспечивая невероятную скорость благодаря своей совместимости. Накопители NVMe работают со всеми основными операционными системами независимо от форм-фактора. NVME (Non-Volatile Memory Express) — это интерфейс связи и драйвер, который использует преимущества увеличенной полосы пропускания, обеспечиваемой PCIe. Он разработан для повышения производительности и эффективности, обеспечивая при этом совместимость с широким спектром корпоративных и клиентских систем. Технология NVMe была разработан для твердотельных накопителей и обменивается данными между интерфейсом хранилища и процессором системы, используя высокоскоростные разъемы PCIe без ограничений форм-фактора. Протокол NVMe использует параллельные пути передачи данных с малой задержкой к базовому носителю, подобно архитектурам высокопроизводительных процессоров. Это обеспечивает значительно более высокую производительность и меньшие задержки по сравнению с протоколами SAS и SATA. NVMe может поддерживать множество очередей ввода-вывода — до 64 тыс. очередей глубиной 64 тыс. записей каждая. В результате задачи ввода/вывода могут передавать больший объем данных быстрее, чем старые модели хранения данных с использованием устаревших драйверов, таких как AHCI (Advanced Host Controller Interface). Поскольку протокол NVMe разработан специально для твердотельных накопителей, он неизбежно станет новым отраслевым стандартом.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	104. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 16-Окт-23, 17:52
	Если даже и есть быстрее, то работать с ними всё равно будешь на скорости памяти, в лучшем случае на скорости какого-нибдуь кеша L3. Любой слой увеличивает задержки доступа к памяти и хоп вроде сети точно не делает жизнь лучше.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	145. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хохлоним (?), 17-Окт-23, 12:50
	Нет,  скорости кеша и оперативной памяти явно больше, а вот чипсет влияет на передачу данных по сети. И мне лично кажется что передача данных параллельно даёт некоторым задачам преимущество перед SATA. Я когда-то давно работал над виртуальной файловой системой, клиентом для гибридного облака и о параллельной передачи данных от жёсткого диска мог только мечтать. Множество параллельных запросов можно сделать, пусть они даже и псевдопаралельные, но они быстрее SATA все-равно оказались и выигрыш скорости не получился. Да и в статьях выше же написано что их используют не только на высоконагруженных серверах, но и в сетевых устройствах для высокой скорости передачи данных, что логично — много информации нужно содержать, правда смотря что за информация. Маршрутизацию все же лучше в оперативной памяти держать.
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хохлоним (?), 17-Окт-23, 13:00
	Хотя, впрочем у меня были определённые претензии к разработчикам серверного API. Мне туда доступ не дали, может и на SATA все получилось. Не удалось договориться об изменении API, другим путём пошли.
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (152), 18-Окт-23, 02:59
	Тут может сработал эффект локов ядра. Поищи про китайцев с их протоколом в пространстве пользователя. А звук на звуковой карте со своей памятью, да еще и аппаратный мог бы быть нормой. Так что если контроллер сетевой на мипсе скажем быстрее делает именно маршрутизацию и передачу данных, то рулить потоками в памяти не очень то и нужно.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	160. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (160), 18-Окт-23, 15:58
	Вообще это хороший вопрос, если он без троллинга, потому что лично я, например, не видел NVMe-oF/TCP и не понимал в нем смысла. Когда люди настраивают NVMe over Fabriс, они понимают что им нужны 2 вещи: 1) Скорость обращения к диску от внешнего сервера, особенно когда речь идёт о низких задержках 2) Снижение требований к центральному процессору, опять это влияет на задержки Дело не в пропускной способности, короче. Тут нужно понять несколько вещей про специфику NVMe и про его подачу через сеть: 1. NVMe контроллер не может быть собран в "аппаратный RAID" Я беру это в кавычки, потому что что называть аппаратным рейдом в 2023 году - тот еще вопрос. NVMe-диск прицепляется напрямую к процессору через PCI Express, в то время как обычные решения про RAID через HBA берут несколько lane-ов и имеют на себе прошивку, чип-сопроцессор и отдельный RAM и подключают диски на себя. Нельзя просто так взять NVMe-диск и воткнуть в "RAID-контроллер", в плату RAID, потому что дело именно в наличии контроллера и прошивки на стороне самого диска (бомжовые берут Generic-прошивку от производителя матплаты, но она всё равно нужна). Ожидается, что вы подключаете NVMe напрямую к соответствующему процессору, поэтому любая блочная абстракция по этим дискам всегда будет программной. 2. В NVMe нет смысла делать RAID 0 Блоки памяти внутри самого диска распараллеливаются. Этот самый RAID0 у вас всегда включен и всегда применяется средствами контроллера NVMe внутри диска. Из-за этого у вас получится так, что программный RAID1 и программный RAID10 на NVMe дисках отличаются по скорости в пределах погрешности, опять же если у вас однопроцессорный сервер и они подключены в рамках одного узла NUMA. Чтобы у вас там все не ломалось есть механизмы коррекции ощибок средствами контроллера по аналогии с Patrol Scrub для RAM. 3. NVMe контроллер не является SCSI-совместимым контроллером Из-за этого у него всё свое в том числе сетевой стек. Ради обратной совместимости поддерживается подача NVMe-дисков через традиционные протоколы впроде iSCSI или FCP (Fiber Channel Protocol), но это не рекомендуется делать. Основные варианты сетевого транспорта NVMe-oF: - NVMe over InfiniBand - NVMe over Fiber Channel - NVMe over Ethernet (имеет несколько вариантов):    - NVMe over RoCE    - NVMe over iWarp    - NVMe over TCP (про него речь в новости) Для обратной совместимости можно подать диски через: - iSCSI - FCoE Из-за технических ограничений API SCSI возникают накладные расходы по работе с командами, поэтому не рекомендуется использовать чистый FC и тем более FCoE, а также iSCSI средствами ОС для работы с этими дисками. Если вы не покупали выделенную Storage-сеть средствами InfiniBand или Fiber Channel (который медленнее и дороже чем даже Infiniband), а пользуетесь Ethernet сетями для организации сети хронения, то вы можете использовать RDMA для подачи этого диска. В зависимости от того, кто производитель вашего сетевого адаптера у вас будет либо RoCE (это по сути RDMA over UDP) или iWarp (это RDMA over TCP). RDMA убирает нагрузку с процессора по работе с сетевым стеком для стораджа и снижает задержки. Протоколы гуглятся. В общем вы уже начали понимать, к чему я клоню... > А какой "use case" у этой технологии? NVMe over TCP будет работать быстрее чем iSCSI, спору нет, но может просто настроить iWarp? Просто RDMA снизит задержки и при правильной конфигурации RoCE выдаст вам прекрасную производительность. В случае с применением 100GB адаптеров Ethernet вы переплюнете абсолютно всё что только можно. Но я могу понять, почему люди этого не делают: - Вам нужны сетевые карты, которые его умеют (Nvidia/Mellanox, Cavium/QLogic, Broadcom) - Вам нужно обратиться к сетевому администратору для настройки сети, потому что вам требуется расширения Ethernet DCB на сети, чтобы это работало правильно Альтернативой является iWarp, который снижает нагрузку на CPU и поддерживается на сетевых адаптерах Chelsio, Intel, Cavium/QLogic. Его настраивать слегка проще, но вам все равно потребуется настроить DCB и lossless-сеть для того чтобы приблизиться к тем низким задержкам, которые даёт RoCEv2. И да, у вас будет TCP. По моему скромному мнению, NVMe over TCP существует для специфического юзкейса, когда вы понакупили себе дисков NVMe в сервера, а на нормальную сетевку вам денег не хватило, поэтому у вас не поддерживается RDMA. Опять же, те кто так производит закуп серверного оборудования скорее всего и про NVMe over TCP не в курсе, поэтому будет настраивать iSCSI себе везде... в общем на ваш вопрос про "use case" у меня нет однозначного ответа.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	169. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от edo (ok), 19-Окт-23, 22:23
	> 1. NVMe контроллер не может быть собран в "аппаратный RAID" Все современные raid от lsi и adaptec (или как они там сейчас называются) умеют nvme-накопители. Или вы про то, что массивы уже не будет nvme-устройством?
	Ответить | Правка | Наверх | Cообщить модератору

19. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	–3 +/–
Сообщение от Аноним (15), 16-Окт-23, 12:22
Фикс просто шедеврален -    goto free_crypto; +    return ret; /* queue removal will cleanup */ -free_crypto: -    if (queue->hdr_digest || queue->data_digest) -        nvmet_tcp_free_crypto(queue); -    return ret; За использование goto просто так, без реальной причины надо бить по рукам.
Ответить | Правка | Наверх | Cообщить модератору

	20. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (20), 16-Окт-23, 12:26
	Ты бредишь. goto не для обезьян-кодеришек. А для системных программистов.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+6 +/–
	Сообщение от Аноним (15), 16-Окт-23, 12:30
	Угу, заметно какой качественный код, навыпрограммировали эти самые "ылитные системные пограммисты"™. Каждую неделю можно наблюдать картину 'это не плохой иструмент' это разработчик неправильный. Уже 30 лет, а дыры одни и те же.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от OpenEcho (?), 16-Окт-23, 12:38
	> За использование goto просто так, без реальной причины надо бить по рукам. Причина надо сказать была и довольно веская, выскочить на метку обработки ошибок без оверхэда, в одну команду (в отличии от вызова другой функции, выделением памяти, потом сворачиванием) это самое эффективное и простое решение где в кернеле применяется очень активно
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	25. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 12:40
	Угу, ценой получения уязвимости, зато как сэкономили! А потом это гото удалили и ничего ужасного не произошло! Может оно там было ненужно?
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от OpenEcho (?), 16-Окт-23, 12:45
	> Угу, ценой получения уязвимости, зато как сэкономили! А причем здесь логическая ошибка и goto?
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от Аноним (15), 16-Окт-23, 12:47
	При том, что лапшекод с goto как раз приводит к логическим ошибкам.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от Анонин (?), 16-Окт-23, 12:43
	> самое эффективное и простое решение ... отстрелить себе ногу И у них таки получилось! Впрочем, не впервой. Вот если бы в языке был какой механизм для таких вещей... типа Defer, то такой проблемы бы не было.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	37. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от OpenEcho (?), 16-Окт-23, 12:54
	Чувак, это кернел ! какой нахер defer когда там все должно летать, ты реализацию defer смотрел? правда все в одну команду ЦПУ укладывается? > Вот если бы в языке был какой механизм для таких вещей... Вон оно что, пусть за меня сделают "защиты и секьюрности" а можно понтоваться потом на тренде. Я тебе секрет открою, что умники с "безопасными" языками, как ни странно забывают очень часто ставить то самый defer... со всеми вытекающими полной защиты от "дураков" - не существует
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Анонин (?), 16-Окт-23, 13:03
	Чувак, это кернел! Он должен быть надежен как бетонная стена, а не ср*ное сито из овна и костылей. Вот в фиксе убрали goto и что? Тормоза начались?
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	–1 +/–
	Сообщение от OpenEcho (?), 16-Окт-23, 13:11
	> Вот в фиксе убрали goto и что? ну так сделай s/goto//g по всему кернелу, очисть от нечести, вот ведь оказывется где собака зарыта Мне жаль тебя... если ты и правда не догнал суть проблемы и едиственное что увидел goto.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (82), 16-Окт-23, 18:42
	> Мне жаль тебя... если ты и правда не догнал суть проблемы и едиственное что увидел goto. Лол, сишники рассказывают про "не догнал суть проблемы". Порода кодерв, которая стабильно из десятилетия в десятилетие наступает на одни и те же грабли, плодит те же CVE, тот же лапшекод - и при этом не делает при этом никаких выводов. И даже наоборот: с упорством барана защищает эту всю дичь. Даже Торвальдс - и тот что то понял и принял в ядро Раст. А на Опеннете от местных экспертов вопли "ты что, это же кэээрнэээл111".
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (82), 16-Окт-23, 16:02
	> ты реализацию defer смотрел? правда все в одну команду ЦПУ укладывается? Ты не поверишь, но да. Даже банальный деструктор в C++ (RAII) инлайниться компилятором прямо в место вызова. Ты бы хоть когда-нибудь вылазил из своего сишного танка...
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	84. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 16:18
	Спарведливости ради речь идет не о продвинутых С++, а о древнем и унылом С. Более того можно вспомнить, что на с11 в ядре преешли аж в 2022 году, а до него был копролитический С89.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Советский инженер (ok), 16-Окт-23, 16:33
	>Спарведливости ради речь идет не о продвинутых С++, а о древнем и унылом С. Спарведливости ради ядро разрабатывают на gcc с кучей gnu extensions. уж и дефер какой никакой могли бы прилепить.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 16:42
	Ты хотел сказать "написать свой велосипед как в истории со split для строк"? О да, это они могли бы! на гитхабе видел даже деферы для СИшки в виде макросов, но наверное оно никому не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Советский инженер (ok), 16-Окт-23, 19:51
	>на гитхабе видел даже деферы для СИшки в виде макросов, но наверное оно никому не нужно. да, в виде макросов это отстой. надо именно на уровне компилятора.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от Аноним (82), 16-Окт-23, 15:59
	>  довольно веская, выскочить на метку обработки ошибок без оверхэда, Да, да, "без оверхеда"... А потом тыкаешь этих горе-оптимизаторов носом в выхлоп ассемблера и профайлера, дабы они наконец-то воочию увидели, что компилятор в состоянии заинлайнить и оптимизировать вызов функции, и что и единственное, чего они добились своим goto - это покрыть все лапшой.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	172. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (171), 20-Окт-23, 15:00
	> без оверхэда, в одну команду Опять эти сказки от сишников, про псевдо-оптимизации исключительно в их фантазиях, когда кошмарные хаки якобы "сэкономили одну команду". При том что реальный код, который крутится на процессоре не похож на их сишный код даже близко, и что они там "сэкономили" процессору неведомо. Потому что уже не 1970-й год.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	27. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от Аноним (24), 16-Окт-23, 12:41
	> За использование goto просто так, без реальной причины надо бить по рукам. Ты походу не то что ни одного модуля для ядра не написал, ты походу вообще с эмбедовкой никогда не работал.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	36. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
	Сообщение от Аноним (15), 16-Окт-23, 12:54
	Что тебе не ясно во фразе "просто так, без реальной причины"? Из кода гото удалили, и... мир не рухнул, код не перестал работать, а наоборот стал лучше. Значит ли это, что в данном случае гото не было жизненно необходимо? Думаю да
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	–1 +/–
	Сообщение от OpenEcho (?), 16-Окт-23, 13:01
	> Значит ли это, что в данном случае гото не было жизненно необходимо? Думаю да Ты или просто троль или правда не втыкаешь, скорее всего как "умный" профессор научил реагировать на goto как красную тряпку, даже не разобравшись. Возьми дизассемблер и посмотри как много jmp в реальности
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (15), 16-Окт-23, 13:09
	Все возможно. Наверное те гореписаки, т.е, простите, уважаемые пограммисты системщики этих самых унтеверситетов не заканчивали, и им профессора не рассказывали о том что "после выделения памяти, ее нужно очищать, желательно всего один раз". Вот так и живем.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 13:18
	Чувак, посмотр на мисру (тот самый С котрый ипользуется для надежности) а именно на правило 15.1 которое объясняется "Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand"
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (68), 16-Окт-23, 15:11
	Замени goto на что-то другое, умник. goto + label - это просто прыжок в конкретный кусок кода (и, внимание) внутри одной функции. Это не longjmp. В этом случае goto выполняет функцию defer, чтобы сразу прыгнуть в один и тот же кусок кода, который и так бы исполнился в конце или при другом условии внутри той же самой функции, и программа просто продолжает исполнятся с места, где определён label. goto убрали в патче, потому что этот defer вообще не нужен внутри функции, она по задумке теперь должна просто return делать. Прыгать в этом случае в label смысла нету никакого. Почитайте исходники, попробуйте написать что-то, что не превращается в 10 вложенных друг в друга циклов и if else стейтментов, после этого приплетайте правила, которые кто-то придумал и выложил в интернет. В Си есть только одно правило - стандарт Си.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (82), 16-Окт-23, 16:05
	> Почитайте исходники, попробуйте написать что-то, что не превращается в 10 вложенных друг в друга циклов и if else стейтментов, после этого приплетайте правила, которые кто-то придумал и выложил в интерне А функции использовать сишечная религия запрещает? Ах, ну да - это же очень медленно (а в профайлер и выхлоп ассембера мы, кончно же, не смотрим).
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Серб (ok), 16-Окт-23, 18:46
	Почитай хотя бы Прешерн "Язык С. Мастерство программирования. Принципы, практики и паттерны". Глава 1. Обработка ошибок. Подраздел: "Переход к обработке ошибки". У него там есть замечание, что при работе в команде могут попастся неадекваты и тогда, возможно, придётся изворачиваться. Ну и варианты изворотов приводит.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (15), 16-Окт-23, 22:45
	Да, и он приводит вполне адекватные решения, например "Поместите инициализацию и очистку в разные функции, как это делается в конструкторах и деструкторах в объектно ориентированном программировании." и примеры проектов где это применяется OpenSSL, OpenWrt, Git. И даже говорит про производительность: "Вместо одной функции мы теперь имеем несколько. Это может снизить производительность, но обычно снижение настолько незначительно, что в большинстве приложений им можно пренебречь." Т.е пока не сделаны замеры профайлера, то делать ранние оптимизации бесполезно. Более того финальный код, который "Оцените, насколько элегантнее стал код по сравнению с первоначальной версией." вообще не содержит goto. Впрочем, я сомневаюсь что писатели этого драйвера, читали такие книги)
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (155), 17-Окт-23, 21:55
	> Впрочем, я сомневаюсь что писатели этого драйвера, читали такие книги) Очевидно, что ты высокого мнения о себе. В том варианте, что ты привел есть существенный недостаток. Это хорошо работает пока ресурсов мало и разработчик один. Как только выделение ресурсов и их освобождение делают в разных местах - обязательно кто-нибудь, когда-нибудь забудет сделать обратную операцию.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хейтер С (?), 17-Окт-23, 09:34
	Rule 15.2 The goto statement shall jump to a label declared later in the same function И? MISRA разрешает goto вперед.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	140. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 17-Окт-23, 09:48
	Это для тех кто не осилил пункт 15.1) Там есть еще 15.3 и 15.4, но и в них есть ремарка Rationale - Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand. Что собственно и видим - получили удалённо эксплуатируемую CVE на ровном месте.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хейтер С (?), 17-Окт-23, 09:59
	CVE не из-за goto. В данном конкретном случае неиспользование goto ничего бы не поменяло.
	Ответить | Правка | Наверх | Cообщить модератору

	144. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 17-Окт-23, 10:58
	CVE из-за наплевательского отношения к работе с памятью и спагетти-кода В хаосе трудно найти какие-то проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хейтер С (?), 17-Окт-23, 16:27
	Суть в том, что код на С без goto для обработки ошибок хуже, RAII-то нет и приходится обмазываться флагами состояний, освобождать ресурсы перед каждым return'ом итп. Да, С хреновый ЯП, но нет, это не спагетти-код.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 13:22
	Rule.15.1 "The goto statement should not be used"
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	91. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (91), 16-Окт-23, 17:01
	goto, jmp - ну ты, блд, сопоставил. Это разный уровень абстракций. Компилятор с языков высокого уровня однозначно нагенерит кучу jmp даже там, где goto и а помине нет. Ну не может машинный код в фигурные скобочки или begin/end.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	173. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (171), 20-Окт-23, 15:07
	> Возьми дизассемблер и посмотри как много jmp в реальности Это не для глючных гомо сапиенсов jmp, а для машин. Мозг гомо сапиенса по определению постоянно ошибается, ему нужны строгие модели и много-много постоянных проверок, чтобы хотя бы снизить количество ляпов на строку. goto для человека - как граната для обезьяны, рано или поздно обязательно подорвётся.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	131. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (131), 16-Окт-23, 23:15
	А ты не заметил, что после goto там еще куски кода были?
	Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

	32. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (68), 16-Окт-23, 12:46
	goto тут при чём? Это вполне себе адекватный defer, чтобы не прописывать как придурок if else с кучей копипаста. Задолбали эти свидетели обучения сишке тех, кто сишку знает лучше. Баг в том, что внутри функции освобождается память, функция возвращается и хендлер очереди освобождает память второй раз, что может привести к RCE. Чёртовы любители прочитать две строчки без остального контекста и выдать мнение о том, как кто что должен писать.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	35. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Анонин (?), 16-Окт-23, 12:48
	Спасибо, мы вот прям сейчас видим как прекрасно они знают сишку)))
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	–1 +/–
	Сообщение от Аноним (20), 16-Окт-23, 15:40
	Да получше тебя, мы это вот прям сейчас видим. Ты рельно уверовал, что узвимость в наличи goto? Рукалицо...
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	–1 +/–
	Сообщение от Аноним (-), 16-Окт-23, 16:54
	Не тебе судить салага. Вердикт о goto вынес Э. Дейкстра, ещё в те времена, когда ты ещё не родился на свет со своим "оверхедом". Дейкстра в своё время нажрался кода FORTRAN, в котором изобиловали GOTO. Это было бичём тех времён.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	98. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (82), 16-Окт-23, 17:20
	> чтобы не прописывать как придурок if else с кучей копипаста У вас какая-то особая сишка, где нет функций?
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	99. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+4 +/–
	Сообщение от Анонин (?), 16-Окт-23, 17:40
	Ты что! Функция же жрет стек и процессорное время! А компилятора, который умеет инлайнить еще не изобрели!
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+3 +/–
	Сообщение от Аноним (15), 16-Окт-23, 17:42
	Сейчас, тебе навалят кучу объяснений: "Код должен быть быстрым, про инлайн мы ничего не знаем, про nested func в гнутых раширениях С, тоже ничего не знаем, пусть в ядре будут дырочки удалённо эксплуатируемые, зато как быстро! Мы тебе уже говорили, что код должен быть быстрым?"
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	126. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (20), 16-Окт-23, 21:41
	Ну да, код должен быть быстрым. Слоупоки не тянут только как и суть спора. Понимаешь же? Или я зря стараюсь?
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 22:38
	Если твоими стараниями по коду CVEшки расползаются, то лучше не надо)
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 22:42
	Стараешься? И это ты называешь "старанием"? А ну начинай стараться в два раза сильнее!
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	142. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (142), 17-Окт-23, 10:12
	> код должен быть быстрым В общем случае — нет, это не главное требование к коду. Обычно ему достаточно не быть тормозным, но квалифицированный прогер такого и не допустит.
	Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

	138. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Хейтер С (?), 17-Окт-23, 08:40
	Нет, goto для ошибок в С хорошо, проще за ресурсами следить, меньше вложенность, меньше кода под ифами. Тут ничего бы не помогло, не дефер, ни если бы ret = kernel_sendmsg(queue->sock, &msg, &iov, 1, iov.iov_len); if (ret < 0) {     if (queue->hdr_digest || queue->data_digest)         nvmet_tcp_free_crypto(queue);     return ret; } так без goto бы было. По сути, тут не было владения ресурсом, поэтому и освобождать его не надо было.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	165. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от PnD (??), 19-Окт-23, 16:11
	В сях через goto реализуется аналог "try…finally" (или "defer") из ЯВУ. Тут большинство народа постоянно путает C с ЯВУ и требует чего-то странного ("переписать на …"). * Я вот, когда для задачи таки нужен C, прямо так и пишу (там где нужен финализатор с зачисткой): goto finally; … finally:
	Ответить | Правка | Наверх | Cообщить модератору

61. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
Сообщение от Sw00p aka Jerom (?), 16-Окт-23, 14:11
NVMe TCP какой ща век ?
Ответить | Правка | Наверх | Cообщить модератору

	70. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (70), 16-Окт-23, 15:20
	А что не так: TCP не актуален или даже NVMe?
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Sw00p aka Jerom (?), 16-Окт-23, 20:12
	>А что не так эт файлзилла на уровне ядра?
	Ответить | Правка | Наверх | Cообщить модератору

64. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
Сообщение от Аноним (64), 16-Окт-23, 14:25
Интересно, когда pull request'ы в ядро проходят review, есть ли принудительное использование статических анализаторов?
Ответить | Правка | Наверх | Cообщить модератору

	76. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (96), 16-Окт-23, 15:41
	Сишка не поддается статическому анализу. Корректность кода нельзя математически доказать.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (15), 16-Окт-23, 16:39
	Не совсем правда. Вот есть seL4, не просто статистически проверено, но даже формально верифицировано. Оно на 73% написана на С, https://github.com/seL4/seL4 Правда есть 2 существенных НО: 1. оно маленькое - там оклоло 36к строк на С, из которых 11к это пустые и комментарии (что уже намекает на сложность). (с другой стороны микроядро и должно быть маленьким) 2. его писали руками, сразу думая о том как они будут его верифицировать. Пришлось потрудиться и использовать Isabelle и Haskell. Кол-во строк скриптов только первой было больше 200к строк. И это было довольно дорого The abstract spec took about 4 person months (pm) to develop. About 2 person years (py) went into the Haskell prototype (over all project phases), including design, documentation, coding, and testing. The executable spec only required setting up the translator; this took 3 pm. The initial C translation was done in 3 weeks, in total the C implementation took about 2 pm, for a total cost of 2.2 py including the Haskell effort. (статья https://cseweb.ucsd.edu/~dstefan/cse227-spring20/papers/sel4...)
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	–1 +/–
	Сообщение от Аноним (102), 16-Окт-23, 17:43
	Формальная верификация - это из области бреда учёных-грантоедов. Отличная теория, которая далека от реалий нашей вселенной.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (82), 16-Окт-23, 19:26
	> Формальная верификация - это из области бреда учёных-грантоедов. Отличная теория, которая далека от реалий нашей вселенной. - Поздраляем, вы приняты в команду разработчиков ядра!
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+1 +/–
	Сообщение от Аноним (91), 16-Окт-23, 19:50
	Ядра Minix.
	Ответить | Правка | Наверх | Cообщить модератору

	161. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (-), 18-Окт-23, 18:21
	Да так. Эндрю Танненбаум брал грант на усовершенствование Миникса3.
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от edo (ok), 19-Окт-23, 22:42
	> Интересно, когда pull request'ы в ядро проходят review, Да. Все патчи публикуются в списках рассылки, где могут высказать свои замечания все желающие. В первую очередь, конечно, высказываются мейнтейнеры этого участка ядра. Потом, если мейнтейнера патч устраивает, он его принимает. Потом мейнтейнеры крупных блоков сбрасывают уже консолидированные патчи Линусу, и он принимает их в основную ветку. Теоретически на каждом шаге после начального принятия кода может происходить отказ/требование доработки, но это уже аварийный механизм, на тот случай, если первый мейнтейнер что-то просмотрел > есть ли принудительное использование статических анализаторов? В описанном выше пути принятия кода статические анализаторы не участвуют. Как и регрессионные тесты. Но есть сторонние команды, которые этим занимаются. За счёт того, что перед каждым релизом ядра код на некоторое время замораживается (принимаются только исправления), у таких проблем есть большие шансы быть замечененными и не попасть в релиз
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

77. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
Сообщение от Аноним (77), 16-Окт-23, 15:46
>В Linux-подсистеме nvmet-tcp (NVMe-oF/TCP), позволяющей обращаться к NVMe-накопителям по сети (NVM Express over Fabrics), используя протокол TCP А просто к оперативной памяти так обращаться можно? Как такое настроить? Хочу поиграться с протоколом и написать свою реализацию клиента.
Ответить | Правка | Наверх | Cообщить модератору

	93. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Менеджер Антона Алексеевича (?), 16-Окт-23, 17:06
	Можно, но не «просто». Гугли RoCE v2.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (91), 16-Окт-23, 17:06
	"Для использования NVMe over RoCE в фабрике, технологию Converged Ethernet должны поддерживать сетевая карта, коммутатор и флэш-массив. Кроме того, сетевая карта и флэш-массив должны поддерживать RoCE (такие сетевые карты сокращенно называются R-NIC)." Наверное, если только написать эмуляцию всего этого.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	95. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (95), 16-Окт-23, 17:07
	>  Хочу поиграться с протоколом и написать свою реализацию клиента. что мешает эмулировать nvme на имимдже в памяти https://qemu-project.gitlab.io/qemu/system/devices/nvme.html
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

136. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+2 +/–
Сообщение от X86 (ok), 17-Окт-23, 07:50
> обращаться к NVMe-накопителям по сети Это какая-то небезопасная штука, которая не должна быть в ядре у всех. Кому надо пускай отдельно устанавливают.
Ответить | Правка | Наверх | Cообщить модератору

	159. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Аноним (159), 18-Окт-23, 09:00
	А оно по умолчанию не у всех, нужны дополнительные телодвижения, чтобы экспортировать nvme по сети. Кстати, накопитель может быть любой, хоть usb, nvme это просто протокол, просто у некоторых накопителей он реализован "в железе".
	Ответить | Правка | Наверх | Cообщить модератору

151. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
Сообщение от Вы забыли заполнить поле Name (?), 17-Окт-23, 19:43
Ну уязвимость и уязвимость. Что бухтеть-то? Пофиксили - это главное. Пофикшеная уязвимость лучше чем не существующий код на безопасном языке. Древние люди с дубинами не могли быть сбитыми автомобилем, а значит жили более безопасно.
Ответить | Правка | Наверх | Cообщить модератору

	163. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Анонин (?), 18-Окт-23, 21:52
	Угу, жили безопасно до глубокой старости, ну... лет до 25-30 в лучше случае)) Зато их мог сожрать саблезубый тигр, или медведь, или просто помереть с голоду... Зато все натуральное было!
	Ответить | Правка | Наверх | Cообщить модератору

	174. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 21-Окт-23, 15:25
	> Угу, жили безопасно до глубокой старости, ну... лет до 25-30 в лучше > случае)) > Зато их мог сожрать саблезубый тигр, или медведь, или просто помереть с > голоду... Зато все натуральное было! Именно. Эволюционно человек расчитан максимум лет на 40 бесперебойной работы. Теперь же умирают не от медведей или тигров (хотя и такое бывает), а от сердечно-сосудистых заболеваний (на первом месте), онкологий и прочего. Об Альцгеймере древние люди и не думали.
	Ответить | Правка | Наверх | Cообщить модератору

176. "Удалённо эксплуатируемая уязвимость в драйвере NVMe-oF/TCP и..."	+/–
Сообщение от Анонин (?), 25-Окт-23, 07:22
Очередное доказательство того, что микроядра лучше
Ответить | Правка | Наверх | Cообщить модератору

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

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