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)
Ответ на: комментарий от sin_a

Если ты про вопрос про кеширование в LXC, то в LXС в PVE нельзя выключить кеширование, в этом нет смысла. Т.е. LXC в безопасносте.

Aceler ★★★★★
()
Ответ на: комментарий от no-dashi-v2

Знаю про битмап на синхронизированые блоки, причём там на бит битмапа может быть совсем не один сектор устройства. Про битмап на TRIM'нутые сектора слышу первый раз. Под «мусор» я подразумевал те сектора, которые ФС освободила и на которые вызвала TRIM. Фактически их содержимое не важно, но на уровне RAID нужны все блоки.

Если есть битмап TRIM'нутых секторов, то откуда взялась проблемма TRIM на RAID4/5/6? Брали бы просто по битмапу, что данный сектор TRIM'нут, а не считывали с SSD и не переживали бы, если SSD вернул не нули.

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

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

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

sin_a ★★★★★
()
Ответ на: комментарий от no-dashi-v2

каждая операция записи получает дополнительный alloc, memcpy и free.

Но ведь буфер под O_DIRECT, ЕМНИП, должен быть выровнен по границе страниц, то есть, в теории, можно лочить страницу, чтобы попытка записи в неё давала page fault и только в этом случае memcpy...

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

Раньше для ext3 ″-o data=journal″ как раз приводила к ошибке при открытии файла с O_DIRECT, а не игнорировала.

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

видимо ты не застал времена большой блокировки в линуксе и ка кот неё долго избавлялись ;-)

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

ну, запретить это я не могу да и ничего плохого от этого не будет

strace поможет. ну или дизнуть. или просто доку посмотреть на используемые программы. =D

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

«У меня за окном такая же девятиэтажка и она не горит.»

Скорее тут вариант «ну как же, видно тех баб в бане, вы попробуйте со шкафа посмотреть»

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

кстати, ещё один случай (кроме O_DIRECT) когда принятое решение вылазит боком в виде разницы на зеркалах - это случай с mmap, который может кончиться на RAID1 этим:
WARNING: mismatch_cnt is not 0 on /dev/mdX

потому что отражённая страница (mmapped page) была изменена между её сохранением по DMA на один диск и на второй. если файл удалили или это была подкачка, то заканчивается всё не совпадающим пустым местом которое даже никто и никогда не будет читать.

mumpster ★★★★★
()
Последнее исправление: mumpster (всего исправлений: 1)

ВСАСНЕ рулит!

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