[LU-16621] File and directory names are not encrypted when using secure boot Created: 06/Mar/23 Updated: 25/Apr/23 Resolved: 13/Mar/23 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | Lustre 2.16.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex Deiter | Assignee: | Alex Deiter |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||
| Severity: | 3 | ||||
| Rank (Obsolete): | 9223372036854775807 | ||||
| Description |
File and directory names are not encrypted when using secure bootSteps to reproduce
Expected results
Expected output+ fscrypt encrypt /mnt/lustre/test ... "/mnt/lustre/test" is now encrypted, unlocked, and ready for use. + cp /etc/passwd /mnt/lustre/test + fscrypt lock /mnt/lustre/test "/mnt/lustre/test" is now locked. + ls -l /mnt/lustre/test -rw-r--r--. 1 stack stack 4096 Feb 17 15:53 iY5cBB+f8Olgcy3H,nCarFqOaTmZuOxEZby9hOSMfBG + md5sum /mnt/lustre/test/iY5cBB+f8Olgcy3H,nCarFqOaTmZuOxEZby9hOSMfBG md5sum: /mnt/lustre/test/iY5cBB+f8Olgcy3H,nCarFqOaTmZuOxEZby9hOSMfBG: Required key not available Actual results
Actual output... + fscrypt encrypt /mnt/lustre/test ... "/mnt/lustre/test" is now encrypted, unlocked, and ready for use. + cp /etc/passwd /mnt/lustre/test + fscrypt lock /mnt/lustre/test "/mnt/lustre/test" is now locked. + ls -l /mnt/lustre/test -rw-r--r--. 1 stack stack 4096 Feb 17 15:51 passwd + md5sum /mnt/lustre/test/passwd md5sum: /mnt/lustre/test/passwd: Required key not available Compatibility and portabilityThe same issue can be reproduced on the Ubuntu 22.04 client(s) with kernel version 5.15.0 when Secure Boot is enabled WorkaroundIf we just disable secure boot, then encryption of directory and file names works as expected Root causeSecure Boot is a verification mechanism for ensuring that code launched by a computer's UEFI firmware is trusted. It is designed to protect a system against malicious code being loaded and executed early in the boot process, before the operating system has been loaded. Secure Boot works using cryptographic checksums and signatures. Each program that is loaded by the firmware includes a signature and a checksum, and before allowing execution the firmware will verify that the program is trusted by validating the checksum and the signature. When Secure Boot is enabled on a system, any attempt to execute an untrusted program will not be allowed. This stops unexpected / unauthorised code from running in the UEFI environment. By its very design, Secure Boot may affect or limit some things that users want to do.
And the ability to directly configure and control devices, so as to prevent the use of a device to access or modify a kernel image:
Certain facilities are restricted:
The most important restrictions for us:
Lustre filesystem and llite (client VFS interface) actively uses the debugfs subsystem and registers many access points there. |
| Comments |
| Comment by Gerrit Updater [ 06/Mar/23 ] |
|
"Alex Deiter <alex.deiter@gmail.com>" uploaded a new patch: https://review.whamcloud.com/c/fs/lustre-release/+/50219 |
| Comment by Sebastien Buisson [ 07/Mar/23 ] |
|
Given that the problem with secure boot is that it prevents access to debugfs, patch #50219 (which is fine) will certainly not be enough to have a functional Lustre client, as there are so many other Lustre parameters handled via debugfs. |
| Comment by Gerrit Updater [ 13/Mar/23 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/c/fs/lustre-release/+/50219/ |
| Comment by Peter Jones [ 13/Mar/23 ] |
|
Landed for 2.16 |