Linux 2.6.12.1

Даже не знаю - радоваться надо (быстрота реагирования на траблы) или огорчаться (ядро только вышло, а к нему уже костыли) ... :)

в фортунки

>Вышел первый стабилизирующий патч для ядра 2.6.12

Забыли написать "для стабильного ядра 2.6.12" :))

наконец то.

а то сдуру обновился - и глюки навалились, виснит все часто и так далее

Ну вот. Глядишь, через месяц-другой 2.6.12.х вполне не страшно будет ставить на продукшн-сервер. А то глюки в ядре сервера с криптованными разделами - далеко не самое приятное, что можно себе представить. :-) А потому всё сейчас на 2.6.11.12 работает.

>Глядишь, через месяц-другой 2.6.12.х вполне не страшно будет ставить на продукшн-сервер

Ты, наверное, хотел сказать "через годик-другой". А, пока, на продакшн - только 2.4.31

нафига на продакшене ядра менять? неужели вас постоянно что то неустраивает и приходится ставить все новые и новые версии ядра

Ну не все так радостно с 2.4.x...

Если криптовать разделы, то на 2.4.х надо ставить crypto-loop (да еще и кучу сторонних модулей к ядру). Соответственно, по полной программе уже можно огрести от одних только глюков loopback-драйвера. Не считая всего остального: например, не очень надежного алгоритма шифрования, ведь он не использует Crypto API из ядра, а юзает какие-то свои собственные библиотеки.

В 2.6.x используется dm-crypt: он делает ремаппинг блочного устройства и, соответственно, никак не использует loopback. А кроме того, интерфейс ядра и поддержка Crypto API (dm-crypt использует его) находятся в мейнстриме ядра, так что с багами тут несколько попроще. Ну и скорости шифрования, соответственно, повыше - ядро-то монолитное и для работе с криптованными разделами оно не использует внешние библиотеки, насколько я понимаю (внешние программы используются только для конфигурации криптования и считывания пароля). С надежностью алгоритмов тоже особо без проблем: выбираешь любой cipher алгоритм из доступных - и шифруй диск на здоровье.

А что, нынче детей допустили к ядерному синтезу? Что за напасть.. уже который релиз жуковский весь.

>Если криптовать разделы, то на 2.4.х надо ставить crypto-loop

Loop-AES? No source code changes to linux kernel. Единственное неудобство - патчить mount/losetup. Дык, ведь, это только один раз..

>С надежностью алгоритмов тоже особо без проблем: выбираешь любой cipher алгоритм из доступных

AES-256 не подходит? twofish, blowfish, serpent, если нужен выбор.

Ну сравши хотябы шедулеры у 2.4 и 2.6 и поймешь :)

> Ну сравши хотябы шедулеры у 2.4 и 2.6 и поймешь :)

Смешно. Как много шедулеров ты сравнивал (срал)? И _как_ ты это делал?

Да я же говорю: в dm-crypt вообще не используется loop!!! Там используется remap! Собственно, в dm-crypt потому и отказались от использования loop, что глючное оно и в 2.4.х и в 2.6.х и никто починкой заняться не удосужился.

AES-256 вполне подходит. Но... ммм... может, я неправильно выразился? crypto-loop страдает скорее плохой _реализацией_ алгоритмов шифрования. Повторяю: crypto-loop не использует Crypto API из ядра, а использует свои собственные библиотеки.

> Ну не все так радостно с 2.4.x... К0шмар как0й....

Мне cpuset'ы нужны :((( Ну чё за грабли, а?

Как понимаю, теперь ждать появления ядра 2.6.13 и юзать 2.6.12.X? %))

> Даже не знаю - радоваться надо (быстрота реагирования на траблы) > или огорчаться (ядро только вышло, а к нему уже костыли) ... :)

Радоваться, однозначно. 8-)

1/ Эксперементальное ядро стабилизируется... Так, смотришь, к версии 2.6.25 и на продакшен можно будет поставить, если все лишнее отключить. 2/ А при ооооочень большой необходимости, ну если по-другому никак, то можно попробовать и сейчас...

Кстати, а зачем Вам, если не секрет, переходить с 2.6.11.12, которое хоть как-то стабилизировано, на 2.6.12?

2.6.11.(10-12) имхо одни из самы стабильных за последнее время

>Если криптовать разделы, то на 2.4.х надо ставить crypto-loop

а нормальные линуксоиды ставят fuse+encfs. и могут использовать все что в openssl есть

Мне кто-нибудь объяснит, почему 2.6.12 оказалось глюкованым, если 2.6.11.[10,11] дошли до более менее стабильного состояния, что за нафиг спрашивается. Откуда они закоммитили код в 2.6.12?

> надо ставить crypto-loop (да еще и кучу сторонних модулей к ядру). > Соответственно, по полной программе уже можно огрести от одних > только глюков loopback-драйвера. Не считая всего остального: > например, не очень надежного алгоритма шифрования, ведь он не > использует Crypto API из ядра, а юзает какие-то свои собственные > библиотеки

Хватит нести чушь! modprobe loop ; modprobe cryptoloop ; modprobe khazad ; losetup -E 18 -e khazad /dev/loop0 /dev/hda5 будет использовать khazad (-E 18 - указание на cryptoloop, -e khazad - это алгоритм khazad из cryptoapi). Или ты скажешь, что в cryptoloop еще и khazad вкомпилирован?! Загляни в cryptoloop и прочти, что там в самом начале написано, что cryptoloop - это шлюз на CryptoAPI.

> Ну и скорости шифрования, соответственно, повыше - ядро-то > монолитное и для работе с криптованными разделами оно не использует > внешние библиотеки

А типа cryptoloop использует внешние библиотеки? Блин... Где такую траву берут??? Аркадий Юрьевич по прозвищу ROOT, ты бы лучше доку да исходники почитал, глядишь бы и отпустил тебя тот забористый отходняк, под которым ты писал свой пост :-)

Ждем 2.6.20.12.

>> надо ставить crypto-loop (да еще и кучу сторонних модулей к ядру). >> Соответственно, по полной программе уже можно огрести от одних > только глюков loopback-драйвера. Не считая всего остального: > например, не очень надежного алгоритма шифрования, ведь он не > использует Crypto API из ядра, а юзает какие-то свои собственные > библиотеки

>Хватит нести чушь! modprobe loop ; modprobe cryptoloop ; modprobe khazad ; losetup -E 18 -e khazad /dev/loop0 /dev/hda5 будет использовать khazad (-E 18 - указание на cryptoloop, -e khazad - это алгоритм khazad из cryptoapi). Или ты скажешь, что в cryptoloop еще и khazad вкомпилирован?! Загляни в cryptoloop и прочти, что там в самом начале написано, что cryptoloop - это шлюз на CryptoAPI.

>> Ну и скорости шифрования, соответственно, повыше - ядро-то > монолитное и для работе с криптованными разделами оно не использует > внешние библиотеки

>А типа cryptoloop использует внешние библиотеки? Блин... Где такую траву берут??? Аркадий Юрьевич по прозвищу ROOT, ты бы лучше доку да исходники почитал, глядишь бы и отпустил тебя тот забористый отходняк, под которым ты писал свой пост :-)

Он наверное имел ввиду crypto-loop от Яри Руссо - он реализовал AES более оптимальным способом и добавил многоключевое (по смыслу говорю, оригинальный перевод будет что-то типа "многорежимный") шифрование, что удаляет так называемую watermark атаку (очень теоретическая и в реальной жизни неприменима) и, естесвенно, несколько повышает и так уже высокую безопасность.

Касательно remap в dm-crypt - ROOT неправ, это отнудь никакой не remap, это достаточно простой хак поверх блочного уровня Linux, гже подменяются оригинальные запросы - очень похоже на cryptoloop (более того, никак иначе это сделать нельзя), только на другом уровне.

По сути все преимущество dm-crypt в его спсобности подключаться к device mapper, он ни чем не лучше в плане безопасности.

Кстати, он _существенно_ медленнее cryptoloop как из ядра, так и от Яри Руссо.

> no-dashi ***

>ты бы лучше доку да исходники почитал, глядишь бы и отпустил тебя тот забористый отходняк

Читать исходники, да к тому же под кайфом? Не, не отпустит!

Поосторожнее надо быть с такими советами. Взрывоопасная смесь. Можно вовсе из путешествия не вернуться.

блин loop-AES рулит

Хм... Ээээ... http://www.linux.com/article.pl?sid=04/06/07/2036205

Вот про ремаппинг:
"dm-crypt provides a crypto layer for Device-mapper. A Device-mapper driver allows you to define new partitions or logical volumes by specifying ranges of sectors on existing block devices."
Перевести? Или, может, ты по-аглицки сам поймешь?

А вот про loopback:
"Previously, cryptoloop has been used to provide encryption by utilizing a loopback device. dm-crypt is a cleaner implementation and provides much more flexibility. According to cryptoloop maintainer Fruhwirth Clemens:

dm-crypt is vastly superior to cryptoloop for a number of reasons:

* It does not suffer from loop.c bugs (there are a lot -- no maintainer)
* dm-crypt does not depend on a special user space tool (util-linux)
* dm-crypt uses mempool, which makes it rock-stable compared to cryptoloop"
Есть вопросы?

А вот про реализацию:
"Although it uses a strong crypto algorithm, cryptoloop is seen as a weak implementation, vulnerable to a certain type of plaintext attack. A discussion of the weaknesses of cryptoloop can be found on LWN.net. Dm-crypt uses the same strong crypto algorithm but with a much improved implementation."
Даже комментировать не надо.

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

Музыки, а вот у мя ~99000 - ~100000 прерываний на 2.6.11 кажется это ненормально а вы как думаете? Флудит кстати rtc.

Да этот нодаши известный перец. Идеот право слово.

Эй дядя, че с прерваниями то делать?

С какими прерываниями? Менструального цикла?

>Менструального цикла?

А это что такое за штука? У мя по cat /proc/interrupt такого не выскакивает. Я же говорю ~100 000 прерываний в секунду. Флудит rtc. Нормально это или нет. (На SuSE 9.3) Ато напишу в нормальный форум, а окажется что так и должно быть - засмеют.

>Хм... Ээээ... http://www.linux.com/article.pl?sid=04/06/07/2036205

>Вот про ремаппинг: "dm-crypt provides a crypto layer for Device-mapper. A Device-mapper driver allows you to define new partitions or logical volumes by specifying ranges of sectors on existing block devices." >Перевести? Или, может, ты по-аглицки сам поймешь?

Это не называется remap. Просто некоторые блочные запросы заворачиваются через device mapper. Ну хорошо, может быть это просто некорректное произношение/название.

>А вот про loopback: >"Previously, cryptoloop has been used to provide encryption by utilizing a loopback device. dm-crypt is a cleaner implementation and provides much more flexibility. According to cryptoloop maintainer Fruhwirth Clemens:

>dm-crypt is vastly superior to cryptoloop for a number of reasons:

>* It does not suffer from loop.c bugs (there are a lot -- no maintainer) >* dm-crypt does not depend on a special user space tool (util-linux) >* dm-crypt uses mempool, which makes it rock-stable compared to cryptoloop" >Есть вопросы?

Он лучше только потому, что удобнее. Но он МЕДЛЕННЕЕ и сложнее.

>А вот про реализацию: >"Although it uses a strong crypto algorithm, cryptoloop is seen as a weak implementation, vulnerable to a certain type of plaintext attack. A discussion of the weaknesses of cryptoloop can be found on LWN.net. Dm-crypt uses the same strong crypto algorithm but with a much improved implementation." >Даже комментировать не надо.

dm-crypt подвержен тем же атакам, т.к. он обратно совместим с cryptoloop :)

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

Кстати, на этом linux.com сидят такие же люди по профессии журналист, которые могут что-то и не знать, более того - именно так и есть.

root@R00T:/dev# cat /proc/driver/rtc
rtc_time : 14:42:02
rtc_date : 2005-06-24
rtc_epoch : 1900
alarm : 22:26:42
DST_enable : no
BCD : yes
24hr : yes
square_wave : no
alarm_IRQ : no
update_IRQ : no
periodic_IRQ : no
periodic_freq : 1024
batt_status : okay

Поток прерываний от rtc может возникнуть по одной из двух причин.
Либо какая-то софтина (vmware?) открывает /dev/rtc и настраивает его на большое количество периодических прерываний.
Либо аппаратная ли низкоуровневая проблема - но это маловероятно, так как "у всех работает".

> Я же говорю ~100 000 прерываний в секунду.

уверены, что не обсчитались? это в любом случае не
нормально. к тому же, rtc может генерить max 8192.

vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 3  0      0  86596   4208 1870652    0    0   204   186 96400   220 96  4  0  0
 3  0      0  93956   4216 1870644    0    0    72     0 96447   512 92  8  0  0
 3  0      0  87236   4220 1871160    0    0   500     0 95734   213 94  7  0  0


cat /proc/interrupts > 000; sleep 1; cat /proc/interrupts >> 000


           CPU0       CPU1       
  0:    1256592    3130219    IO-APIC-edge  timer
  1:       5330          3    IO-APIC-edge  i8042
  4:       3251          1    IO-APIC-edge  serial
  7:          0          0    IO-APIC-edge  parport0
  8:  212938356  207937521   IO-APIC-level  rtc
 12:         99          3    IO-APIC-edge  i8042
177:         65         65   IO-APIC-level  acpi
185:      88943        101   IO-APIC-level  aic7xxx
193:         18         12   IO-APIC-level  aic7xxx
201:      83178          1   IO-APIC-level  eth0
209:     194546          1   IO-APIC-level  eth1
NMI:          0          0 
LOC:    4386806    4386805 
ERR:          0
MIS:          0

           CPU0       CPU1       
  0:    1257609    3130219    IO-APIC-edge  timer
  1:       5330          3    IO-APIC-edge  i8042
  4:       3251          1    IO-APIC-edge  serial
  7:          0          0    IO-APIC-edge  parport0
  8:  212985889  207986458   IO-APIC-level  rtc
 12:         99          3    IO-APIC-edge  i8042
177:         65         65   IO-APIC-level  acpi
185:      88962        101   IO-APIC-level  aic7xxx
193:         18         12   IO-APIC-level  aic7xxx
201:      83185          1   IO-APIC-level  eth0
209:     194567          1   IO-APIC-level  eth1
NMI:          0          0 
LOC:    4387823    4387822 
ERR:          0
MIS:          0

странно. я, вообще-то, никогда rtc driver не включал,
могу ошибаться, но не должно быть такого...

а что в /proc/driver/rtc ?
и что в dmesg | grep -i rtc

и вообще, гляньте в syslog/dmesg

и в /proc/driver/rtc
и в логах никаких аномалий  нет.

в /proc/driver/rtc вообще все *_IRQ стоят в no, частота 1024. Сейчас поставлю ядро от RHEL4 и посмотрю что будет ...

>могу ошибаться, но не должно быть такого...

Ясно дело. Должно быть в пределах 1K. А тут на порядок больше.

>Поток прерываний от rtc может возникнуть по одной из двух причин. Либо какая-то софтина (vmware?) открывает /dev/rtc и настраивает его на большое количество периодических прерываний.

Можно попробовать fuser /dev/rtc но похоже проблема не в этом ...

>Можно попробовать fuser /dev/rtc но похоже проблема не в этом ...

Однозначно дело не в этом. Да и нету там никого.

>а зачем Вам, если не секрет, переходить с 2.6.11.12, которое хоть >как-то стабилизировано, на 2.6.12?
Тут же неоднократно заявляли что 2.6.12 содержит все bugfix'ы из 2.6.11.x !

> Although it uses a strong crypto algorithm, cryptoloop is seen as a weak implementation

Прежде чем раскидываться словами, подумай и реши - в каком месте оно weak? Пока не сумеешь обосновать, сиди и не вянгай.

После вот ЭТОГО: "Повторяю: crypto-loop не использует Crypto API из ядра, а использует свои собственные библиотеки" (c) ROOT 23.06.2005 16:03:24 тебе бы вообще следовало изобразить смущеный смайлик и пойти читать исходники.

В отличие от тебя, я смотрел в них и знаю, что cryptoloop и dm_crypt отличаются только точкой подключения, причем можно без особых усилий создать encryption для loop, позволяющий при знании ключа прочесть данные, созданные dm_crypt и наоборот: в dm_crypt изначально заложено два способа генерации вектора инициализации (надеюсь, ты в курсе что это такое), один из которых нужно "повторить" в этом loop-transfer'е.

P.S.: про ремап тебе писал анонимус... а по скорости они отличаются

P.P.S.: рассуждать про loop/cryptoloop/dm_crypt/cryptoapi скорее уж пристало мне, поскольку в отличие от тебя я таки с некоторым успехом "just for fun" реализовывал гостовский алгоритм в качестве кифера к loop и алгоритма в cryptoapi :-)