В 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.dev/opennews/art.shtml?num=59940
освободил память? - присвой указателю нулл
Используешь C? - перестань
Переходи на С++?
Хотя бы. Уже станет лучше.
Но только если на современные плюсы, а не на сишку с классами.
В плюсах при низкоуровневой разработке способов прострелить себе колено пожалуй даже больше чем в C
т.е мы приходим к теореме г-на Эскобара?
Что С плохо (как видим из новости), что С++ не лучше.Вот бы придумали способ находить, а лучше предотвращать такие ошибки заранее, может какой-то новый язык написали)
Хотя тут ИМХО даже стат анализатор помог бы, но кто его запускать будет, это же долго.
Такие ошибки предотвращать относительно просто, это указатели с экслюзивным владением и счётчики ссылок. Автор модуля банально не осилил сделать корректное управление указателем, здесь нет никакой сложной низкоуровщены. В этой же дичи всё ещё goto используют. Если в этот долбанутый Си добавили хотя бы RAII, и научили несчастных им пользоваться, то значительной части уязвимостей просто бы не было.
Так каждый раз когда приходит кто-то с предложениями улучшить процессы (я уже молчу про большие изменения, вроде 'добавить Раст') типа "а давайте сделаем стат. анадизатор обязательным, или добавим линтер", то начинается нытье "будет медленно, не хочу ждать 10 минут пока тесты пробегут" в перемежку с пафосными рассуждениями об ылитных пограммитах который этот код наделали, что ядро пишут только профи, которым это не нужно.
Ядро с сопредельным софтом сначала придётся переписать полностью. Для смены языка.
Для смены языка - да. Это очень сложный путь.А обязательные стат. анализаторы?
Ты думаешь, что их добавление приведет к нерешаемым проблемам?
Да, наверное придется месяц-два потратить на исправление всех проблем, но лучше это чем такие уязвимости.
Очередной раз придурки не знают что такое Компоновщик/Линковщик?
уж вы-то лучше всех бы накодировали, без единой ошибки
На ночь через крон ставить не?
> В плюсах при низкоуровневой разработке способов прострелить себе колено пожалуй даже больше
> чем в CЧтобы не прострелить себе ногу достаточно не направлять на нее ружье, не?
=====================
Учитель, почему, когда я делаю так
int *a;
a = new int;
char *b;
*a=1000;
b=a;
*b='0';
cout<< 1000/a <<"\n";
Получается фигня?- Не делай так!
а это точно соберётся? там присвоение немного неодинаковых типов может вывести компилятор из себя
> а это точно соберётся? там присвоение немного неодинаковых типов может вывести компилятор
> из себяКод в таком виде большинство компиляторов откажется собирать. Но мысль, как и можно с указателями намудрить так, чтобы программа таки работала все, а по факту был идиотский результат, хватит.
ето потому что к malloc/free добавили еще new/delete или что?
> В плюсах при низкоуровневой разработке способов прострелить себе колено пожалуй даже больше чем в CХоть один пример приведете?
> Но только если на современные плюсы, а не на сишку с классами.Да даже если и на сишку с классам: наличие RAII уже само по себе избавило бы от этого убогого цирка с ручным управлением ресурсами и соответствующих CVE.
RAII уже включили в ядро... В Rust.
> Да даже если и на сишку с классам: наличие RAII уже само по себе избавило бы от этого убогого цирка с ручным управлением ресурсами и соответствующих CVE.Не избавило бы. Сишникам только дай волю, они сразу полезут делать malloc'и и хранить строки в char*. У них квадратно-гнездовое мышление, переучить очень сложно. Типа "я 30 лет так делал и менять свои привычки не собираюсь, компилятор подвинься". Ну а потом естественно всё это феерично взрывается.
Комитету C++ нужно отправить весь этот сишный треш в утиль.
если не с классами то с чем?
Используешь не С - перестань, с чего это такие глупые призывы. ХОТЯ ДА, нынче если Ваше ПО не жрёт фигову тучу ресурсов - это не гууд... нужно по 2-3гб и по 100% нагрузке на проц на всякую бессмыслицу что бы быть в тренде ... так получается ?
> нужно по 2-3гб и по 100% нагрузке на проц на всякую бессмыслицуНет чувак. Это даже не проблема языка программирования, а лично разраба.
Согласен, но ... только при одних и тех же обстоятельствах производительность и потребление ресурсов у разных языков разное. И как бы ты не старался для оптимизации работы некоторые вещи лучше писать на асме.... увы знаю о чём говорю... и Си и С++ в этом плане шибко проигрывают чистой асме.Не говоря о том что многие разрабы в место того что бы реализовать маленькую фигню самим тащат монструозные зависимости которые ничего не делают, жрут ресурсы и весят балластом ) Так что да у многих прогеров нынче с этим беда...
> Си и С++ в этом плане шибко проигрывают чистой асмеВот только сколько такого "горячего" кода в приложении? 20%? 10%? Еще меньше?
Предварительная оптимизация - это зло.
А пару маленьких кусков можно и на асме переписать потом, когда уже будут результаты работы профайлера.
> Вот только сколько такого "горячего" кода в приложении? 20%? 10%? Еще меньше?Да, всё зависит от конкретных задач и конкретного приложения, тупейший пример: рендеринг, расчёт физики и т.п. (там где много ветвлений и циклов) производительность будет падать в разы а не каких то 10/20%.
А теперь что касается реальных задач и конкретной темы в ядре падение скорости даже 2-3% уже сказывается на работу всего софта который был затронут зависимостями... там эти 2-3% могут как снежный ком расти... и в итоге ты будешь к примеру играть не 60fps а 45-48 потому что в коде оказался код который "тормозит" на 2-3%. вот это круто да.... понимаю всего 2-3% а не 10 и не 20%...
> Предварительная оптимизация - это зло.Конечно, легче говно код написать и сказать что сейчас делать софт можно и нужно который и озу и проц жрут из расчёта что "У ВСЕХ ЕСТЬ ВОЗМОЖНОСТЬ КУПИТЬ НОВЫЙ КОМ" или новый сервер.... %)
> А пару маленьких кусков можно и на асме переписать потом, когда уже
> будут результаты работы профайлера.Вообще согласен, но иногда это код гораздо легче переписать с нуля чем исправлять и оптимизировать уже существующий ...
p.s.
Можете кидаться какахами но увы... % на % и на % уже водном месте , в другом в и в третьем ... они же зачастую суммируются...У народа тормозит, не справляется, не хватает мощи - не твои проблемы проблемы клиента, не оптимизируй код, пусть лучше он купит новое железо или добавит ещё пару пару десятков гб озу )))...
Увы но Я в корпоративной среде много такого кода видел из этого расчёта написанного ))), да можно работать но иногда просто офигиваешь от того что не шибко сложные вещи могут давать такие нагрузки....
мб просто я уже старый пердун, но в МОЁ ВРЕМЯ все старались писать оптимизированный код сразу а не после того как жаренный петух клюнет...
> легче говно код написатьприкольно ты в противовес супер-оптимизированному асму ставишь сразу говнокод))
т.е. есть только черное и белое? не пишешь на асме - сразу говнокод?)
современные компиляторы прекрасно оптимизируют код, при этом нужно тратить время на те места, где компилятор не справился> я уже старый пердун, но в МОЁ ВРЕМЯ
возможно в то время средний погромист был умнее компилятора
но увы, те времена прошли, и слава богу))> все старались писать оптимизированный код сразу
Похвально, вот только сколько времени ты будешь писать оптимизированный код на асме?
Пока ты будешь это делать, Вася на си уже напишет не такой оптимальный и он уже будет решать задачу.
Потому Васю попросят (или не попросят) ускорить свой код, а твой.. ну, останется у тебя.
> прикольно ты в противовес супер-оптимизированному асму ставишь сразу говнокод))Эм, похоже у кого-то с логикой не всё хорошо и делает выводы из своих же фактов ? Я утрировал и речь шла о том что предварительная оптимизация зачастую плюс, или ты собираешься пузырьковым методом сортировать массивы ?
> современные компиляторы прекрасно оптимизируют код, при этом нужно тратить время на те
> места, где компилятор не справилсяДа, но даже они проигрывают в рациональности и пониманию целей и оптимизации человека.
> возможно в то время средний погромист был умнее компилятора
> но увы, те времена прошли, и слава богу))Через чур уверенное заявление ...
> Похвально, вот только сколько времени ты будешь писать оптимизированный код на асме?
И так я буду писать на 10-30% дольше, в зависимости от задачи, так как есть понимание где и какой подход в каких обстоятельствах лучше использовать.
Далее, речь шла не только об асме (чего до него докопались то ?) но и о простых оптимизациях в коде, брутфорс наше всё и конечно он хорошо справляется, маленький легко понятный код ))).... На примере строки, как ты будешь производить поиск в огромном объёме ? На удивление простой перебор циклом не очень хорошая идея )))
> Пока ты будешь это делать, Вася на си уже напишет не такой
> оптимальный и он уже будет решать задачу.Пока у Васи код будет выполняться 10 часов мой выполнится за 10 минут. Пока это разовое задача/действие - да подход Васи предпочтителен, но стоит запустить его больше раз... Хотя мб в этом и цель, что бы оправдания найти или выполнять одну и туже работу дважды ?
> Потому Васю попросят (или не попросят) ускорить свой код, а твой.. ну,
> останется у тебя.Если Вася не умеет писать более менее оптимальный код и не может структурировать его в голове, то и оптимизация у него будет на уровне ...
Того, что сказано выше - достаточно.
Осталось всего-лишь как-то заставить всех выполнять выполнять это элементарное действие.
Всего-лишь...
А еще - программы надо проектировать. Тогда и на си можно будет норм. писать(и даже без зануления указателей).
Везде так, сначала проектируют, потом реализовывают и только в программировании "самодокументируемый код".
А как вообще можно проэктирвоать архитектуру опенсорса?
Без шуток, я понимаю как оно делается в проприетарных проектах, но в распределнном проекте на тысячи человек.
Ну т.е даже если есть архитектор который придумал как оно должно быть и как нужно реализовывать.
А потом приходит кто-то с уже готовым кодом, который... ну не влазит в архитектуру.
И есть выбор: попросить переделать или ждать пока кто-то другой реализует, но это может быть долго. (а может и никогда)Может кто-то сталкивался как решают такие диллемы?
тысячи человек, приходит с кодом.. ну ты и фантазёр (тут я не шучу, ты явно никогда в ОС движении не был) - почему-то вспоминаются постановочные скриншоты слака:- Кто может взять этот баг?
- Конечно я!
> ты явно никогда в ОС движении не былКонечно не был, поэтому и спрашиваю)
Просто пример ехФАТ дров - был драйвер самсунг, но он был устаревший и требовал допиливания (насколь понимаю сама самсунг на него уже давно забила).
И тут приходит Paragon и приносит на блюдечке драйвер.Как согласовывали требования к драйверу и что бы было если бы они на них забили, но драйвер все равно работает. Взяли бы его в ядро или нет?
эти люди делают это за деньги - они сразу знают как, в "эти люди" включены и менеджеры, которые знают о рисках.
Ну почему сразу постановочные? У меня такое было и не раз.
Смотришь в борду - а там все такое унылое и муторное... а тут кто-то находит интересную критику!
И да, пишу, что с удовольствием займусь этим багом))
> А еще - программы надо проектировать. Тогда и на си можно будет норм. писать(и даже без зануления указателей).Не смешите... Сишные кудесники, бедненькие, в одной функции запутались: то память дважды освободят, то за пределы буфера вылезут - а вы им проектирование хотите поручить? Бракоделам, которые без goto и сотни строк не в состоянии написать?
Ну и будет локальный указатель внутри функции указывать на NULL, ок. А тысячи других указателей, которые не в курсе, что ты один локальный указатель обнулил, что делать будут? Или ты предлагаешь всё переписать на двойной указатель или вообще не безопасТный язык?
уязвимость в новости - дабл фри
> тысячи других указателейЕсли ты присвоил один и тот же указатель тысяче разных мест, а затем без всякой координации освобождаешь в каком-то одном месте, а затем получаешь double-free, то это в первую очередь характеризует тебя. Как человека, которого к сям подпускать нельзя. (ЧСХ, именно такие на сях и пишут.)
Среди сишников бытует мнение, что "ptr = NULL" — это очень долгая операция, и нужно экономить такты.
Ничего тут не медленно, просто бесполезно, потому что это никак не влияет на другие указатели.
чувак, если у тебя один и тот же кусок памяти используется многими структурами, следует наконец ввести ref/unref или прочие техники управления памятью. Указатели у него, видите ли, "не влияются". Твоя претензия смехотворна, ибо double-free возникает при НЕиспользовании техник типа подсчета ссылок -- то есть как раз там, где такие техники и не нужны, ибо памятью владеет кто-то один. Кто-то один, кто забыл обнулить единственный указатель на память.
Не нужон нам ваш ref/unref.
Какому именно указателю? Их может быть несколько в совершенно разных структурах.
А, ну да, тогда никак. Придется дважды освобождать память. А иногда и десятижды.^ ты же к этому выводу всех склоняешь?
Склоняю к тому, что use-after-free и double free возникают по другим причинам.
Можно занулить _свой_ указатель - но надо ещё убедиться, что другие структуры уничтожены либо сделаны то же самое.
То есть просто зануление не спасёт.
Haha, classic.
"Прошло 5 дней с последней сишной дырени"
Подскажите, с целью повышения уровня образованности. А какой "use case" у этой технологии? Уже есть сети, быстрее оперативы? Честно, не троллю, хотелось бы получше разобраться.
> Уже есть сети, быстрее оперативыНет. Просто в оперативу всё не влазит(( Даже в стойку нужное кол-во nмme не влазит.
Приходится ставить рядом еще одну, читать оттуда и терпеть просадки по перформансу.
Вот такая вот печалька. Но что поделать.
Тогда нужен RDMA, а не поделие из топика
RDMA сам по себе не решает проблему доступа к удалённому блочному устройству.
А оффлоады nvmeo* уже есть в сетевых картах, кстати
Да.
https://ru.wikipedia.org/wiki/DDR_SDRAM#%D0%A1...
SSD уже догнали ддр4?
Ты в пример привел какое-то старье. Даже у уже устаревшей DDR4-2400 - bandwidth 19200 MB/s.
А у DDR5 - 38400 для стандартной 4800 и 57600 для 7200.
А у фибры - максимум 25600 MB/s, и то - только на самой распоследней.
Оптика уже 600 гигабит умеет. Ну нафиг ненужно распределенную базу данных при распределенных вычислениях гонять через цпу который офигеет.
Не просто же так начали жпу натаскивать на чтение из накопителя напрямую. Это даже при локальном использовании желательно.
Подскажите лучше, как контролировать все что работает на gpu, а то проц молчит, а gpu дает доступ ко всему что на компе без вашего согласия :)
Как более современная замена iSCSI.
> Подскажите, с целью повышения уровня образованности. А какой "use case" у этой технологии?Это тоже самое что и iSCSCI, только позволяющее гигантские очереди и пути, и как результат увеличение пропускной способности и уменьшение задержек и при всем этом не надо какого-то специфического железа
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 (для клиента порт генерируется операционной системой).
И вот в итоге: 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 так не сделаешь
Очереди и в sata есть, гораздо более жиденькие, конечно, но для большинства задач достаточные
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.
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 разработан специально для твердотельных накопителей, он неизбежно станет новым отраслевым стандартом.
Если даже и есть быстрее, то работать с ними всё равно будешь на скорости памяти, в лучшем случае на скорости какого-нибдуь кеша L3. Любой слой увеличивает задержки доступа к памяти и хоп вроде сети точно не делает жизнь лучше.
Нет, скорости кеша и оперативной памяти явно больше, а вот чипсет влияет на передачу данных по сети. И мне лично кажется что передача данных параллельно даёт некоторым задачам преимущество перед SATA. Я когда-то давно работал над виртуальной файловой системой, клиентом для гибридного облака и о параллельной передачи данных от жёсткого диска мог только мечтать. Множество параллельных запросов можно сделать, пусть они даже и псевдопаралельные, но они быстрее SATA все-равно оказались и выигрыш скорости не получился. Да и в статьях выше же написано что их используют не только на высоконагруженных серверах, но и в сетевых устройствах для высокой скорости передачи данных, что логично — много информации нужно содержать, правда смотря что за информация. Маршрутизацию все же лучше в оперативной памяти держать.
Хотя, впрочем у меня были определённые претензии к разработчикам серверного API. Мне туда доступ не дали, может и на SATA все получилось. Не удалось договориться об изменении API, другим путём пошли.
Тут может сработал эффект локов ядра. Поищи про китайцев с их протоколом в пространстве пользователя.
А звук на звуковой карте со своей памятью, да еще и аппаратный мог бы быть нормой.
Так что если контроллер сетевой на мипсе скажем быстрее делает именно маршрутизацию и передачу данных, то рулить потоками в памяти не очень то и нужно.
Вообще это хороший вопрос, если он без троллинга, потому что лично я, например, не видел 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" у меня нет однозначного ответа.
> 1. NVMe контроллер не может быть собран в "аппаратный RAID"Все современные raid от lsi и adaptec (или как они там сейчас называются) умеют nvme-накопители.
Или вы про то, что массивы уже не будет nvme-устройством?
Фикс просто шедеврален
- 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 просто так, без реальной причины надо бить по рукам.
Ты бредишь. goto не для обезьян-кодеришек. А для системных программистов.
Угу, заметно какой качественный код, навыпрограммировали эти самые "ылитные системные пограммисты"™.Каждую неделю можно наблюдать картину 'это не плохой иструмент' это разработчик неправильный.
Уже 30 лет, а дыры одни и те же.
> За использование goto просто так, без реальной причины надо бить по рукам.Причина надо сказать была и довольно веская, выскочить на метку обработки ошибок без оверхэда, в одну команду (в отличии от вызова другой функции, выделением памяти, потом сворачиванием) это самое эффективное и простое решение где в кернеле применяется очень активно
Угу, ценой получения уязвимости, зато как сэкономили!
А потом это гото удалили и ничего ужасного не произошло!
Может оно там было ненужно?
> Угу, ценой получения уязвимости, зато как сэкономили!А причем здесь логическая ошибка и goto?
При том, что лапшекод с goto как раз приводит к логическим ошибкам.
> самое эффективное и простое решение... отстрелить себе ногу
И у них таки получилось! Впрочем, не впервой.
Вот если бы в языке был какой механизм для таких вещей... типа Defer, то такой проблемы бы не было.
Чувак, это кернел ! какой нахер defer когда там все должно летать, ты реализацию defer смотрел? правда все в одну команду ЦПУ укладывается?> Вот если бы в языке был какой механизм для таких вещей...
Вон оно что, пусть за меня сделают "защиты и секьюрности" а можно понтоваться потом на тренде.
Я тебе секрет открою, что умники с "безопасными" языками, как ни странно забывают очень часто ставить то самый defer... со всеми вытекающими
полной защиты от "дураков" - не существует
Чувак, это кернел! Он должен быть надежен как бетонная стена, а не ср*ное сито из овна и костылей.
Вот в фиксе убрали goto и что? Тормоза начались?
> Вот в фиксе убрали goto и что?ну так сделай s/goto//g по всему кернелу, очисть от нечести, вот ведь оказывется где собака зарыта
Мне жаль тебя... если ты и правда не догнал суть проблемы и едиственное что увидел goto.
> Мне жаль тебя... если ты и правда не догнал суть проблемы и едиственное что увидел goto.Лол, сишники рассказывают про "не догнал суть проблемы". Порода кодерв, которая стабильно из десятилетия в десятилетие наступает на одни и те же грабли, плодит те же CVE, тот же лапшекод - и при этом не делает при этом никаких выводов. И даже наоборот: с упорством барана защищает эту всю дичь.
Даже Торвальдс - и тот что то понял и принял в ядро Раст. А на Опеннете от местных экспертов вопли "ты что, это же кэээрнэээл111".
> ты реализацию defer смотрел? правда все в одну команду ЦПУ укладывается?Ты не поверишь, но да. Даже банальный деструктор в C++ (RAII) инлайниться компилятором прямо в место вызова.
Ты бы хоть когда-нибудь вылазил из своего сишного танка...
Спарведливости ради речь идет не о продвинутых С++, а о древнем и унылом С.
Более того можно вспомнить, что на с11 в ядре преешли аж в 2022 году, а до него был копролитический С89.
>Спарведливости ради речь идет не о продвинутых С++, а о древнем и унылом С.Спарведливости ради ядро разрабатывают на gcc с кучей gnu extensions. уж и дефер какой никакой могли бы прилепить.
Ты хотел сказать "написать свой велосипед как в истории со split для строк"?
О да, это они могли бы!на гитхабе видел даже деферы для СИшки в виде макросов, но наверное оно никому не нужно.
>на гитхабе видел даже деферы для СИшки в виде макросов, но наверное оно никому не нужно.да, в виде макросов это отстой. надо именно на уровне компилятора.
> довольно веская, выскочить на метку обработки ошибок без оверхэда,Да, да, "без оверхеда"... А потом тыкаешь этих горе-оптимизаторов носом в выхлоп ассемблера и профайлера, дабы они наконец-то воочию увидели, что компилятор в состоянии заинлайнить и оптимизировать вызов функции, и что и единственное, чего они добились своим goto - это покрыть все лапшой.
> без оверхэда, в одну командуОпять эти сказки от сишников, про псевдо-оптимизации исключительно в их фантазиях, когда кошмарные хаки якобы "сэкономили одну команду". При том что реальный код, который крутится на процессоре не похож на их сишный код даже близко, и что они там "сэкономили" процессору неведомо. Потому что уже не 1970-й год.
> За использование goto просто так, без реальной причины надо бить по рукам.Ты походу не то что ни одного модуля для ядра не написал, ты походу вообще с эмбедовкой никогда не работал.
Что тебе не ясно во фразе "просто так, без реальной причины"?
Из кода гото удалили, и... мир не рухнул, код не перестал работать, а наоборот стал лучше.
Значит ли это, что в данном случае гото не было жизненно необходимо? Думаю да
> Значит ли это, что в данном случае гото не было жизненно необходимо? Думаю даТы или просто троль или правда не втыкаешь, скорее всего как "умный" профессор научил реагировать на goto как красную тряпку, даже не разобравшись. Возьми дизассемблер и посмотри как много jmp в реальности
Все возможно.
Наверное те гореписаки, т.е, простите, уважаемые пограммисты системщики этих самых унтеверситетов не заканчивали, и им профессора не рассказывали о том что "после выделения памяти, ее нужно очищать, желательно всего один раз".
Вот так и живем.
Чувак, посмотр на мисру (тот самый С котрый ипользуется для надежности)
а именно на правило
15.1 которое объясняется "Unconstrained use of goto can lead to programs that are unstructured and extremely difficult to understand"
Замени goto на что-то другое, умник. goto + label - это просто прыжок в конкретный кусок кода (и, внимание) внутри одной функции. Это не longjmp. В этом случае goto выполняет функцию defer, чтобы сразу прыгнуть в один и тот же кусок кода, который и так бы исполнился в конце или при другом условии внутри той же самой функции, и программа просто продолжает исполнятся с места, где определён label.
goto убрали в патче, потому что этот defer вообще не нужен внутри функции, она по задумке теперь должна просто return делать. Прыгать в этом случае в label смысла нету никакого.
Почитайте исходники, попробуйте написать что-то, что не превращается в 10 вложенных друг в друга циклов и if else стейтментов, после этого приплетайте правила, которые кто-то придумал и выложил в интернет. В Си есть только одно правило - стандарт Си.
> Почитайте исходники, попробуйте написать что-то, что не превращается в 10 вложенных друг в друга циклов и if else стейтментов, после этого приплетайте правила, которые кто-то придумал и выложил в интернеА функции использовать сишечная религия запрещает? Ах, ну да - это же очень медленно (а в профайлер и выхлоп ассембера мы, кончно же, не смотрим).
Почитай хотя бы Прешерн "Язык С. Мастерство программирования. Принципы, практики и паттерны".Глава 1. Обработка ошибок.
Подраздел: "Переход к обработке ошибки".
У него там есть замечание, что при работе в команде могут попастся неадекваты и тогда, возможно, придётся изворачиваться. Ну и варианты изворотов приводит.
Да, и он приводит вполне адекватные решения, например "Поместите инициализацию и очистку в разные функции, как это делается в конструкторах и деструкторах в объектно ориентированном программировании." и примеры проектов где это применяется OpenSSL, OpenWrt, Git.И даже говорит про производительность:
"Вместо одной функции мы теперь имеем несколько. Это может снизить производительность, но обычно снижение настолько незначительно, что в большинстве приложений им можно пренебречь."Т.е пока не сделаны замеры профайлера, то делать ранние оптимизации бесполезно.
Более того финальный код, который "Оцените, насколько элегантнее стал код по сравнению с первоначальной версией." вообще не содержит goto.
Впрочем, я сомневаюсь что писатели этого драйвера, читали такие книги)
> Впрочем, я сомневаюсь что писатели этого драйвера, читали такие книги)Очевидно, что ты высокого мнения о себе.
В том варианте, что ты привел есть существенный недостаток. Это хорошо работает пока ресурсов мало и разработчик один.
Как только выделение ресурсов и их освобождение делают в разных местах - обязательно кто-нибудь, когда-нибудь забудет сделать обратную операцию.
Rule 15.2 The goto statement shall jump to a label declared later in the same
functionИ? MISRA разрешает goto вперед.
Это для тех кто не осилил пункт 15.1)Там есть еще 15.3 и 15.4, но и в них есть ремарка
Rationale - Unconstrained use of goto can lead to programs that are unstructured and extremely
difficult to understand.
Что собственно и видим - получили удалённо эксплуатируемую CVE на ровном месте.
CVE не из-за goto. В данном конкретном случае неиспользование goto ничего бы не поменяло.
CVE из-за наплевательского отношения к работе с памятью и спагетти-кода
В хаосе трудно найти какие-то проблемы.
Суть в том, что код на С без goto для обработки ошибок хуже, RAII-то нет и приходится обмазываться флагами состояний, освобождать ресурсы перед каждым return'ом итп. Да, С хреновый ЯП, но нет, это не спагетти-код.
Rule.15.1 "The goto statement should not be used"
goto, jmp - ну ты, блд, сопоставил. Это разный уровень абстракций. Компилятор с языков высокого уровня однозначно нагенерит кучу jmp даже там, где goto и а помине нет. Ну не может машинный код в фигурные скобочки или begin/end.
> Возьми дизассемблер и посмотри как много jmp в реальностиЭто не для глючных гомо сапиенсов jmp, а для машин. Мозг гомо сапиенса по определению постоянно ошибается, ему нужны строгие модели и много-много постоянных проверок, чтобы хотя бы снизить количество ляпов на строку. goto для человека - как граната для обезьяны, рано или поздно обязательно подорвётся.
А ты не заметил, что после goto там еще куски кода были?
goto тут при чём? Это вполне себе адекватный defer, чтобы не прописывать как придурок if else с кучей копипаста. Задолбали эти свидетели обучения сишке тех, кто сишку знает лучше.Баг в том, что внутри функции освобождается память, функция возвращается и хендлер очереди освобождает память второй раз, что может привести к RCE.
Чёртовы любители прочитать две строчки без остального контекста и выдать мнение о том, как кто что должен писать.
Спасибо, мы вот прям сейчас видим как прекрасно они знают сишку)))
Да получше тебя, мы это вот прям сейчас видим. Ты рельно уверовал, что узвимость в наличи goto? Рукалицо...
Не тебе судить салага. Вердикт о goto вынес Э. Дейкстра, ещё в те времена, когда ты ещё не родился на свет со своим "оверхедом". Дейкстра в своё время нажрался кода FORTRAN, в котором изобиловали GOTO. Это было бичём тех времён.
> чтобы не прописывать как придурок if else с кучей копипастаУ вас какая-то особая сишка, где нет функций?
Ты что! Функция же жрет стек и процессорное время!
А компилятора, который умеет инлайнить еще не изобрели!
Сейчас, тебе навалят кучу объяснений:
"Код должен быть быстрым, про инлайн мы ничего не знаем,
про nested func в гнутых раширениях С, тоже ничего не знаем,
пусть в ядре будут дырочки удалённо эксплуатируемые, зато как быстро!
Мы тебе уже говорили, что код должен быть быстрым?"
Ну да, код должен быть быстрым. Слоупоки не тянут только как и суть спора. Понимаешь же? Или я зря стараюсь?
Если твоими стараниями по коду CVEшки расползаются, то лучше не надо)
Стараешься? И это ты называешь "старанием"?
А ну начинай стараться в два раза сильнее!
> код должен быть быстрымВ общем случае — нет, это не главное требование к коду. Обычно ему достаточно не быть тормозным, но квалифицированный прогер такого и не допустит.
Нет, 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 бы было. По сути, тут не было владения ресурсом, поэтому и освобождать его не надо было.
В сях через goto реализуется аналог "try…finally" (или "defer") из ЯВУ.
Тут большинство народа постоянно путает C с ЯВУ и требует чего-то странного ("переписать на …").* Я вот, когда для задачи таки нужен C, прямо так и пишу (там где нужен финализатор с зачисткой):
goto finally;
…
finally:
NVMe TCP какой ща век ?
А что не так: TCP не актуален или даже NVMe?
>А что не такэт файлзилла на уровне ядра?
Интересно, когда pull request'ы в ядро проходят review, есть ли принудительное использование статических анализаторов?
Сишка не поддается статическому анализу. Корректность кода нельзя математически доказать.
Не совсем правда.
Вот есть 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...)
Формальная верификация - это из области бреда учёных-грантоедов. Отличная теория, которая далека от реалий нашей вселенной.
> Формальная верификация - это из области бреда учёных-грантоедов. Отличная теория, которая далека от реалий нашей вселенной.- Поздраляем, вы приняты в команду разработчиков ядра!
Ядра Minix.
Да так. Эндрю Танненбаум брал грант на усовершенствование Миникса3.
> Интересно, когда pull request'ы в ядро проходят review,Да. Все патчи публикуются в списках рассылки, где могут высказать свои замечания все желающие. В первую очередь, конечно, высказываются мейнтейнеры этого участка ядра.
Потом, если мейнтейнера патч устраивает, он его принимает.
Потом мейнтейнеры крупных блоков сбрасывают уже консолидированные патчи Линусу, и он принимает их в основную ветку.Теоретически на каждом шаге после начального принятия кода может происходить отказ/требование доработки, но это уже аварийный механизм, на тот случай, если первый мейнтейнер что-то просмотрел
> есть ли принудительное использование статических анализаторов?
В описанном выше пути принятия кода статические анализаторы не участвуют. Как и регрессионные тесты. Но есть сторонние команды, которые этим занимаются. За счёт того, что перед каждым релизом ядра код на некоторое время замораживается (принимаются только исправления), у таких проблем есть большие шансы быть замечененными и не попасть в релиз
>В Linux-подсистеме nvmet-tcp (NVMe-oF/TCP), позволяющей обращаться к NVMe-накопителям по сети (NVM Express over Fabrics), используя протокол TCPА просто к оперативной памяти так обращаться можно? Как такое настроить? Хочу поиграться с протоколом и написать свою реализацию клиента.
Можно, но не «просто». Гугли RoCE v2.
"Для использования NVMe over RoCE в фабрике, технологию Converged Ethernet должны поддерживать сетевая карта, коммутатор и флэш-массив. Кроме того, сетевая карта и флэш-массив должны поддерживать RoCE (такие сетевые карты сокращенно называются R-NIC)."
Наверное, если только написать эмуляцию всего этого.
> Хочу поиграться с протоколом и написать свою реализацию клиента.что мешает эмулировать nvme на имимдже в памяти
https://qemu-project.gitlab.io/qemu/system/devices/nvme.html
> обращаться к NVMe-накопителям по сетиЭто какая-то небезопасная штука, которая не должна быть в ядре у всех. Кому надо пускай отдельно устанавливают.
А оно по умолчанию не у всех, нужны дополнительные телодвижения, чтобы экспортировать nvme по сети. Кстати, накопитель может быть любой, хоть usb, nvme это просто протокол, просто у некоторых накопителей он реализован "в железе".
Ну уязвимость и уязвимость. Что бухтеть-то? Пофиксили - это главное. Пофикшеная уязвимость лучше чем не существующий код на безопасном языке. Древние люди с дубинами не могли быть сбитыми автомобилем, а значит жили более безопасно.
Угу, жили безопасно до глубокой старости, ну... лет до 25-30 в лучше случае))
Зато их мог сожрать саблезубый тигр, или медведь, или просто помереть с голоду... Зато все натуральное было!
> Угу, жили безопасно до глубокой старости, ну... лет до 25-30 в лучше
> случае))
> Зато их мог сожрать саблезубый тигр, или медведь, или просто помереть с
> голоду... Зато все натуральное было!Именно. Эволюционно человек расчитан максимум лет на 40 бесперебойной работы. Теперь же умирают не от медведей или тигров (хотя и такое бывает), а от сердечно-сосудистых заболеваний (на первом месте), онкологий и прочего. Об Альцгеймере древние люди и не думали.
Очередное доказательство того, что микроядра лучше