LINUX.ORG.RU

Проблема флага O_DIRECT

 , , ,

Проблема флага O_DIRECT

3

6

Даже пользователь без прав администратора способен вызвать необратимую рассинхронизацию дисков.

В Linux обнаружена серьёзная уязвимость, существующая уже более десяти лет, и связана она с механизмом программного RAID при использовании флага O_DIRECT. Проблема позволяет привести массив в несогласованное состояние, причём без каких-либо ошибок или предупреждений со стороны системы. Несмотря на то, что баг впервые был зарегистрирован ещё в 2015 году, интерес к нему вновь возрос в контексте современных задач, таких как живая миграция виртуальных машин.

Суть проблемы заключается в том, как пользовательские программы взаимодействуют с блочными устройствами при помощи O_DIRECT. Этот флаг позволяет выполнять прямой доступ к данным, минуя кеш ядра, что полезно для повышения производительности в ряде задач. Однако в случае программного RAID, такого как MD RAID, DRBD или LVM RAID, это приводит к тому, что каждый диск массива может получить разные данные, даже если они записываются с одного и того же указателя в пользовательском пространстве. В результате данные на отдельных устройствах перестают быть синхронизированными – массив остаётся «рабочим» с точки зрения системы, но фактически оказывается повреждённым.

Причём проблема не в самих данных, а в нарушении согласованности между дисками. Даже если данные представляют собой «мусор», они должны быть одинаковыми на каждом RAID-устройстве. В текущем же случае каждый диск получает свою версию этих данных. Причина в том, что каждый из драйверов нижнего уровня получает доступ к одной и той же области пользовательской памяти независимо друг от друга, что приводит к расхождениям при чтении и записи.

Уязвимость считается особенно опасной, так как может быть вызвана из пользовательского пространства без прав суперпользователя, если программа имеет доступ к файлу на RAID-массиве и использует O_DIRECT. Это означает, что RAID может быть повреждён обычным приложением, даже не подозревающим об этом эффекте. При этом никаких ошибок или предупреждений от ядра не поступает, и массив продолжает функционировать как будто ничего не произошло.

Из всех файловых систем Linux, известны только две, не подверженные этому дефекту при использовании с программным RAID – это OpenZFS и Bcachefs. Остальные решения остаются потенциально уязвимыми. Проблема до сих пор числится как открытая и не имеет официального исправления.

>>> Подробности

★★★★★

Проверено: dataman ()
Последнее исправление: hobbit (всего исправлений: 3)
Ответ на: комментарий от mrdeath

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

anc ★★★★★
()
Ответ на: комментарий от ckotctvo

рейд использует кэш ядра, директ сбрасывает данные минуя кэш. тащемта, это написано в тексте новости. и на софтовом уровне эту проблему не решить. это можно решать на уровне FS, например.

Iron_Bug ★★★★★
()
Ответ на: комментарий от pekmop1024

Нет, он их и тримнул и всё и никуда не записал, что эти блоки «освобождены». Иначе не было бы проблемы с trim на MD Raid5/6.

mky ★★★★★
()
Ответ на: комментарий от mumpster

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от mumpster

там ведь ещё bit rot и т.п. могут нарисоваться. а это никакими исправлениями в ПО не исправишь. только хранить избыточность и КС.

используй dm-integrity, если боишься bitrot

pekmop1024 ★★★★★
()
Ответ на: комментарий от mky

Нет, он их и тримнул и всё и никуда не записал, что эти блоки «освобождены». Иначе не было бы проблемы с trim на MD Raid5/6.

Он никуда записывать не должен. Эта команда уходит в nvme/sata/scsi устройство и уже прошивка обрабатывает её внутри, помечая свободные блоки.

Нужно правильно слои настраивать. У меня, например, discard спокойно пролазит до nvme через ext4@lvm@dm-crypt@mdadm@dm-integrity. Правда, далеко не все nvme устройства умеют правильно репортить результат (например, самсунги PM серии и 990 PRO умеют, а WD SN850X всегда репортит NUSE = NCAP).

С RAID 5/6 другая проблема, там сложная структура данных, подразумевающая 100% заполнение диска.

pekmop1024 ★★★★★
()
Последнее исправление: pekmop1024 (всего исправлений: 1)
Ответ на: комментарий от nempyxa

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

Кому не интересны? Спрос на них такой, что тот HPE не знает где закупить достаточное количество, предлагая клиентам «аналоги, не уступающие по характеристикам».

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

обрабатывает её внутри

Правильно.

100% заполнение диска.

А ″echo check > /sys/block/md0/md/sync_action″ для MD RAID1 не подразумевает 100% заполнения? Не будут проверены на одинаковость все блоки у двух накопителей? RAID1 как-то знает, где данные ФС, а где мусор?

mky ★★★★★
()
Ответ на: комментарий от Aceler

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

Вот есть ли изначальные гарантии, что такое невозможно — это большой вопрос.

А так-то да, «по нашей улице уже 30 лет ходят три вооруженных человека, но они же ни в кого не стреляют, живут они тут»... :)

gns ★★★★★
()
Ответ на: комментарий от mky

А ″echo check > /sys/block/md0/md/sync_action″ для MD RAID1 не подразумевает 100% заполнения? Не будут проверены на одинаковость все блоки у двух накопителей? RAID1 как-то знает, где данные ФС, а где мусор?

За «где данные, а где мусор» отвечает dm-integrity. Который просто выдаст ошибку чтения, если будет «мусор» и mdadm самопочинится с зеркала.

pekmop1024 ★★★★★
()
Ответ на: комментарий от mky

Что касается пустых блоков, в силу нативной поддержки discard со стороны mdadm, никто их не проверяет ни на что, кроме того, что они помечены как пустые.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

что они помечены как пустые

Ну-ну. Тогда не было бы проблемы с TRIM на RAID5. Именно нужно, чтобы SSD гарантировано возвращал нули при чтении TRIM'нутого блока.

mky ★★★★★
()
Ответ на: комментарий от mky

Ну-ну. Тогда не было бы проблемы с TRIM на RAID5. Именно нужно, чтобы SSD гарантировано возвращал нули при чтении TRIM’нутого блока.

Советую посмотреть, как как выглядят данные в RAID5/6 на уровне нижележащего блочного устройства (члена массива). В случае RAID1 это просто тупое зеркало, его даже без mdadm можно примонтировать и работать.

pekmop1024 ★★★★★
()
Последнее исправление: pekmop1024 (всего исправлений: 1)
Ответ на: комментарий от pekmop1024

Советую прочитать https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-raid.html....

И прочитать первое сообщение, с чего началась эта ветка. Там было про то, что зеркало рассыпится при check.

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

Там как раз написано то, что я тебе пытаюсь объяснить - «почему на RAID5/6 оно так не будет работать в принципе».

pekmop1024 ★★★★★
()
Ответ на: комментарий от mky

И прочитать первое сообщение, с чего началась эта ветка. Там было про то, что зеркало рассыпится при check.

Судя по тому, что багу 10 лет и его никто не фиксит, это не баг, скорее аналог молдавского вируса, разработчики которого настолько бедны, что вирус уговаривает пользователей удалять данные самостоятельно.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Вы не хотите отвечать, что именно происходит при check RAID1.

Нет, в тупите и гоните пургу:

Что касается пустых блоков, в силу нативной поддержки discard со стороны mdadm, никто их не проверяет ни на что, кроме того, что они помечены как пустые.

Там как раз написано, что MD raid не знает какие блоки пустые и читает с накопителя всё подряд. И важно, чтобы при чтении пустого блока SSD возвращал нули. Если бы MD raid знал, что блок пустой (TRIM), то он бы его не читал, а сам бы генерил нули.

mky ★★★★★
()
Ответ на: комментарий от mky

Вы не хотите отвечать, что именно происходит при check RAID1.

Ему технически прочитать все нужно так или иначе. И дискарднутый сектор - это не «возвращение нуля», так как «нуль» это тоже данные. Это специфическое состояние сектора.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Не знаю, тут написали, что это вылазит, если на хосте софтовый RAID1, а на госте будет swap на этот RAID1.

настолько бедны,

возможно правда, держать виртуалки на хосте с софтовым зеркалом, явно не признак финансового благополучия :)

mky ★★★★★
()
Ответ на: комментарий от mky

Не знаю, тут написали, что это вылазит, если на хосте софтовый RAID1, а на госте будет swap на этот RAID1.

Держу гипервизоры на KVM со времен Debian 6 (Squeeze), ни разу такой рейд у меня не пострадал. Правда, я костылями не пользуюсь, потому допускаю, что в проксмксе могли великие специалисты чего-нибудь натюнить во имя святого перформанса вокруг O_DIRECT, получив такую лажу.

Собственно, потому я подобными вещами и не пользуюсь.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Да, специфическое состояние сектора. Но ведь ОС про это узнать не может, накопитель что-то возвращает при чтении и желательно, чтобы возвращал нули.

У меня, когда была синхронизация RAID1, то на один из SSD было записан полный объём md-устройства, не смотря на то, что данных на уровне ФС было мало, и TRIM работал, не использованые сектора были «пустые».

Исходно утверждается, что если с помощью этого бага мы испортим файл на RAID 1, то так как на хосте постоянно делается check, то всё рассыпится. Но, если у нас SSD такие, что они не возвращают нули после TRIM сектора, то при check и это зеркало рассыпится?

То есть я к тому, что куча RAID 1 на непонятных SSD, и среди них явно нашлись бы с проблемным TRIM и на них check вызывал бы ошибку или синхронизацию. Или все пофиг и никто это на это внимание не обращал?

mky ★★★★★
()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

Да, специфическое состояние сектора. Но ведь ОС про это узнать не может, накопитель что-то возвращает при чтении и желательно, чтобы возвращал нули.

Блочное устройство (это не обязательно физический накопитель, это может быть и device mapper) как раз репортит именно специфическое состояние сектора, именно поэтому для discard требуется поддержка со стороны ОС, блочного устройства и файловой системы. Если помнишь, когда SSD только появились, это было проблемой какое-то время. Не все ОС умели, не все device mapper’ы умели (и до сих пор не все умеют, например, если настроить integrity внутри dm-crypt, про discard забудь).

Исходно утверждается, что если с помощью этого бага мы испортим файл на RAID 1, то так как на хосте постоянно делается check, то всё рассыпится. Но, если у нас SSD такие, что они не возвращают нули после TRIM сектора, то при check и это зеркало рассыпится?

Мне другое интересно - как себя dm-integrity поведет. У меня mdadm состоит как раз из этих device mapper’ов.

pekmop1024 ★★★★★
()
Ответ на: комментарий от mky

То есть я к тому, что куча RAID 1 на непонятных SSD, и среди них явно нашлись бы с проблемным TRIM и на них check вызывал бы ошибку или синхронизацию. Или все пофиг и никто это на это внимание не обращал?

У меня был кейс дохнущего SSD, из-за которого check триггерился минимум раз в день. Рейд тот жив и поныне, после замены SSD. Но, опять же, никакого кастомного тюнинга, всюду safe defaults.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Блочное устройство раз репортит именно специфическое состояние сектора,

Что я такого не помню в стандарте SATA. И во всяких советах, как проверить, что TRIM работает, не было, что мы можем от SSD получить список TRIM'нутых секторов.

И проблемы, которые я помню, что ОС просто не умела давать накопителю команду «сделай TRIM этого сектора». Но они просто работали на SATA SSD и их можно было заставить почитать «пустые» области SSD.

P.S. Сходил по ссылке, где описана проблема. Пока дочитал, что после check просто растёт /sys/block/md0/md/mismatch_cnt, на который, видимо, все пофиг.

mky ★★★★★
()
Ответ на: комментарий от pekmop1024

индустрии они неинтересны. 1. прошли те времена 90ые), когда аппаратный рейд с собственным процессором существенно разгружал ЦП. сейчас нет разницы в производительности. т.е. прибавки производительности аппаратный рейд давно не дает. 2. аппаратный рейд - вещь в себе. усложнен мониторинг состояния и контроль производительности. многие операции с ним плохо задокументированы или вообще невозможны. не все контроллеры даже умеют jbod, и существует такое извращение, когда ради jbod лепятся куча рейдов по одному диску на рейд… 3. надежность. какие ваши действия, если помирает/глючит контроллер. расскажете процедуру быстрой массива миграции с гарантий сохранности данных на дисках? это что называется: пока не попробуешь - не узнаешь как оно на самом деле. а вот с mdadm давно всё понятно. 4. бигтех аппаратные рейды не жалует. смотрим подход яндекс клауд по железным серверам: https://yandex.cloud/ru/docs/baremetal/operations/servers/switch-raid-member - общие рекомендации, инструкция по замене диска на mdadm: https://yandex.cloud/ru/docs/baremetal/concepts/server-advanced-settings , получается, если клиент создаст рейд на контроллере, то это будут его трудности. хотя замена неисправного диска - это типовая по сути плановая ситуация обслуживания сервера. более простая картина в cloud.ru: https://cloud.ru/products/evolution-bare-metal

nempyxa ★★
()
Ответ на: комментарий от mky

В SATA discard реализовывали vendor-зависимо, когда появилась необходимость (потому было столько копий сломано о том, какая прошивка работает стабильнее), ибо когда делали стандарт, его ни на что серьезное не готовили. В SCSI/SAS и NVME уже всё в стандарте.

pekmop1024 ★★★★★
()
Ответ на: комментарий от nempyxa

Публичные облака - это не вся индустрия, мягко говоря.

Все твои аргументы выдают в тебе человека, не сталкивавшегося с большими сетапами bare metal, особенно было смешно читать про усложнение мониторинга.

В отличие от софтовых массивов, аппаратные мониторятся out of the box, а не из ОС.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Ну, хорошо, не SATA. Для SAS или NVME есть какая-то консольная утилита/команда, чтобы узнать список дискарднутых блоков накопителя?

mky ★★★★★
()
Ответ на: комментарий от mky

Да, можно посмотреть lba status. Правда, на большинстве консумерского говна это порезано.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

А этот самый dm-integrity уже научили не затирать диски по полгода во время integritysetup format? В последний раз, когда я пытался воспользоваться этим, format --no-wipe приводил к dm-1: unrecoverable I/O read error for block 266089080 уже на этапе mkfs.

thriller ★★
()
Ответ на: комментарий от thriller

А этот самый dm-integrity уже научили не затирать диски по полгода во время integritysetup format? В последний раз, когда я пытался воспользоваться этим, format –no-wipe приводил к dm-1: unrecoverable I/O read error for block 266089080 уже на этапе mkfs.

А ты знаешь толк! Еще, поди, и lazy init в ext4 не выключаешь?

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

В отличие от софтовых массивов, аппаратные мониторятся out of the box, а не из ОС.

И без ОС же могут отправить письмо о вылете диска? Без ОС могут отдать чиселку со статусом массива заббиксу/прометею?

thriller ★★
()
Ответ на: комментарий от pekmop1024

С lazy init ФС хотя бы можно пользоваться, с dm-integrity приходится либо сидеть без ФС, либо ждать, пока диск закончит запись терабайтов и терабайтов бессмысленно верифицированных нулей.

thriller ★★
()
Ответ на: комментарий от thriller

И без ОС же могут отправить письмо о вылете диска? Без ОС могут отдать чиселку со статусом массива заббиксу/прометею?

Именно так. Слышал о таких вещах, как RedFish API и SNMP? :)

pekmop1024 ★★★★★
()
Ответ на: комментарий от thriller

С lazy init ФС хотя бы можно пользоваться, с dm-integrity приходится либо сидеть без ФС, либо ждать, пока диск закончит запись терабайтов и терабайтов бессмысленно верифицированных нулей.

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

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

С ZFS таких проблем нет. Придумывает их сам себе как раз-таки dm-integrity (-:

thriller ★★
()
Ответ на: комментарий от thriller

И сколько 3rd-party-контроллеров можно обозреть через него?

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

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

pekmop1024 ★★★★★
()
Ответ на: комментарий от thriller

С ZFS таких проблем нет.

Угу. Нет данных - нет проблем. :)

pekmop1024 ★★★★★
()
Ответ на: комментарий от thriller

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

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от pekmop1024

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

Тогда непонятно, почему в этом треде вы рассуждаете о dm-integrity, а не рекламируете NetApp.

thriller ★★
()
Ответ на: комментарий от thriller

Тогда непонятно, почему в этом треде вы рассуждаете о dm-integrity, а не рекламируете NetApp.

Я у себя дома тоже не держу то, что мне не подходит. Странно, если бы было иначе, правда?

pekmop1024 ★★★★★
()
Ответ на: комментарий от vbr

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

Еще лучше: мониторинг создает тикет через API, мужик уже знает, к какой стойке ему идти, в каком юните стоит сервер, нужно ли договориваться о даунтайме, где лежит запасной диск и куда положить дохлый.

Причем это не мужик, работающий в компании, которой принадлежит сервер и мониторинг, а инженер по гарантийному обслуживанию HPE или Dell.

pekmop1024 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.