https://bugzilla.novell.com/show_bug.cgi?id=345039 Summary: Encrypted filesystem write blocks the system Product: openSUSE 10.3 Version: Final Platform: i686 OS/Version: openSUSE 10.3 Status: NEW Severity: Normal Priority: P5 - None Component: Security AssignedTo: security-team@suse.de ReportedBy: robin.listas@telefonica.net QAContact: qa@suse.de Found By: --- (I classify this provisionally as a security problem, considering encryption a security feature; please reclassify as needed). Setup description (longish) ---------------------------- I have several encrypted filesystems inherited from 10.2 and before (system has been upgraded during the time from 8.1 up to 10.3; ie, I don't use fresh install). CPU is a P-IV, 1GiB, and I have 3 HD (± 300, 120 & 60 GB) and more than 16 partitions on two of them. The main encrypted partition is activated via "/etc/init.d/boot.crypto start" during boot up, and /etc/cryptotab: /dev/loop0 /dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15 \ /cripta xfs twofish256 noatime,nodiratime It is mounted via loop0, /dev/mapper/cryptotab_loop0, and I think /dev/dm-0, but exactly how, I don't understand (please, documentation anywhere :-?) nimrodel:~ # mount -l | grep cripta /dev/mapper/cryptotab_loop0 on /cripta type xfs (rw,noatime,nodiratime) [crypta_320] nimrodel:~ # dmsetup info Name: cryptotab_loop0 State: ACTIVE Tables present: LIVE Open count: 1 Event number: 0 Major, minor: 253, 0 Number of targets: 1 That one has not given problems as far as I know. However, I have three more encripted filesystems, on file (not partitions) and mounted manually. Many of the files stored on them are 300-400 MiB. One of the filesystem is largish (28GiB), and the other two have the exact size of a DVD (4.4GiB), because I burn the file directly to a DVD as my backup procedure. Thus, I can also mount encrypted DVDs from the command line using "mount" as user, and all this through entries in fstab: /biggy/crypta_f.mm.x /mnt/crypta.mm.x xfs \ noauto,user,noatime,nodiratime,loop,encryption=twofish256 1 4 /Grande/imgs/crypta_f1_dvd.mm.x /mnt/crypta.mm_dvd1.x xfs \ noauto,user,loop,encryption=twofish256 1 4 /Grande/imgs/crypta_f2_dvd.mm.x /mnt/crypta.mm_dvd2.x xfs \ noauto,user,loop,encryption=twofish256 1 4 nimrodel:~ # mount -l | grep twofish /biggy/crypta_f.mm.x on /mnt/crypta.mm.x type xfs (rw,noexec,nosuid,nodev,noatime,nodiratime,loop=/dev/loop1,encryption=twofish256) nimrodel:~ # losetup -a /dev/loop0: [000e]:4593 (/dev/disk/by-id/ata-ST3320620A_5QF2M56F-part15) /dev/loop1: [1650]:135 (/biggy/crypta_f.mm.x), encryption twofish (type 18), key length 32 This setup has worked very well while using 10.2, but in 10.3 I have problems: I experience filesystem crash or lock up when writing to the large encrypted one. Problem description -------------------- Reading from /mnt/crypta.mm.x (28GiB) works (I managed to copy it elsewhere without a glitch). However, writing to this filesystem, from one of the encrypted DVDs fail. To clear out the DVD subsystem, I copied over the DVD using dd to a file, and loopmounted that one: /dev/loop4: [0314]:9142822 (/Grande/imgs/roto), encryption twofish (type 18), key length 32 Well, whatever the data source, writing to /mnt/crypta.mm.x a set of large files (over 300 MiB each), locks the console where the copy is having place. The copy process stops. It is unkillable. Umount of that filesystem locks (and umount is unkillable). Logout of GNome locks if an xterm locked by this problem. Reboot of system locks, requiring hard power off, and later, filesystem repair (not, it seems, of /mnt/crypta.mm.x). If gnome is active, I see in the CPU system monitor applet that "IOWait" is 100%, but cpu ussage is very low (encryption uses a lot of cpu here). gkrellm ends by freezing. If I try to "ls -l" the destination dir of the copy (that is locked, frozen), the terminal doing this ls also freezes. I have to lazy umount ("umount -l /mountpoints &") all the mountpoints I can, and then try to reboot (which hangs), and finally poweroff the machine forcefully. There is absolutely nothing in the logs relative to this problem (I believe I know how to look into logs and find problems, even if not understanding them; that was my work specialty some years ago O:-) ). I have fsck the encrypted filesystem, nothing reported: nimrodel:~ # losetup -e twofish256 /dev/loop2 /biggy/crypta_f.mm.x Password: nimrodel:~ # file -s /dev/loop2 /dev/loop2: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) nimrodel:~ # xfs_check /dev/loop2 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. nimrodel:~ # mount /dev/loop2 /mnt/crypta.mm.x/ nimrodel:~ # umount /dev/loop2 nimrodel:~ # xfs_check /dev/loop2 nimrodel:~ # No errors, you see. I'm aware that the encryption filesystem method have changed in 10.3, but the only document I have is the release notes. Probably I would have to use a different method than losetup, but I have no idea which exactly. But notice that the problem arises from a filesystem mounted directly from fstab - shouldn't this method be used now anymore? I can not mount this partition from /etc/cryptotab as I need to mount and umount it manually, at will. In any case, the "classic" method should not freeze the computer, as it does :-? I can run tests; right now I think I can reproduce the situation at will, as I had to reboot several times yesterday while trying to diagnose it (several hours). But please, be careful with the suggested tests, as a failure means powering off forcefully, which means a minimum of half an hour per test, providing I don't loose data in the process. So far I have been lucky. And please, try to limit tests to runlevel 3, as a gnome lockup plays havoc with things like command history and some gadgets. I haven't seen any messages related to the lock. Not in dmesg, not in consoles, log files, etc. nothing. Not related to the problem even remotely, and sometimes not a message about anything at all. I'm willing to recompile the kernel and increase verbosity somewhere, if you know that somewhere (I don't). Mmmm... I think I wrote all I know about it. I hope you can decipher the problem! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.