Dear Carlos, Quoting Carlos E. R. (robin.listas@telefonica.net):
Yes, the swap can be encrypted, and during resume the kernel messages mentions that fact. I don't know if it uses LUKS or something else.
Using that method, however, during boot the system would ask for the passphrase twice or more: once for the root system (another for /home, if used), and another for swap ?¹?.
When following the aforementioned SDB article in creating several encrypted partitions (all with luks), the system only asks for one passphrase during boot in case all passphrases are the same. To be more precise, it asks for first passphrase, unlocks first partition, then for the next partition it first tries with the first passphrase and only asks for a new one if the first one does not do the job. I did't test with a scenario where the first and second passphrase differ, and the third is equal to the first, so I do not know if for a third partition both first and second would be checked before prompting for third passphrase.
On restore from hibernation, it would ask for the password only once: for the swap. The partitions are mounted, no password required.
It's the other way 'round here too, at least in my setting: It *does* ask for *all* passphrases on restore from hibernation too. Maybe that's due to the fact that the information about which partitions to unlock is given as kernel boot parameters. I might try a more YaST-guided setup next, where all partitions safe root (which cannot be done) are encrypted already by YaST. Maybe I will find a better combination of kernel boot parameters and initrd-scripts when using that. (Better in the sense that on wakeup only the resume partition's passphrase will be needed.) That might take a day or two though.
I wonder what would happen on a failed wake up, would the fsck script ask for the password, or would it fail?
I don't think so. If I understand correctly, fsck checks the partitions given by root and by /etc/fstab. The root given to fsck is the next layer above the device mapper, which means the already-unlocked partition. If unlocking fails, fsck cannot even find the device it should check.
Another possibility would be hardware encryption, directly by the HD firmware. Search for "ATA Security Feature Set" in man hdparm. I have never used this in Linux - I know of people that used it in windows. I don't know who has to ask for the password, I think the bios: not even the MBR can be read if the lock is set.
I will look into that. Thanks! Susan Dittmar -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-security+help@opensuse.org