SGksCgpJJ20gY29uZmlndXJpbmcgYSBuZXcgRGViaWFuIGluc3RhbGxhdGlvbiBvbiBteSB3b3Jr c3RhdGlvbiwgd2l0aCBib3RoIHRoZSAvYm9vdCBwYXJ0aXRpb24gYW5kIHRoZSByb290IGZpbGVz eXN0ZW0gZW5jcnlwdGVkOgotIC9kZXYvbnZtZTBuMXAxIC0+IC9FRkkKLSAvZGV2L252bWUwbjFw MiAtPiBMVUtTMiAocGJrZGYyKSAtPiAvYm9vdAotIC9kZXYvbnZtZTBuMXAzIC0+IExVS1MyIC0+ IExWTSBjb250YWluaW5nIHJvb3QgYW5kIG90aGVyIHZvbHVtZXMKClRoZSBzeXN0ZW0gYm9vdHMs IGJ1dCByZXF1aXJlcyBlbnRlcmluZyB0aGUgL2Jvb3QgcGFzc3dvcmQgdHdpY2U6Ck9uY2UgZm9y IEdSVUIsIGFuZCBvbmNlIGFnYWluIGR1cmluZyBzeXN0ZW1kIGluaXRpYWxpemF0aW9uLgoKQm90 aCBkZXZpY2VzIGFyZSBwcm9wZXJseSBjb25maWd1cmVkIGluIC9ldGMvY3J5cHR0YWIgd2l0aCB0 aGUgVVVJRHMgZm9yIC9kZXYvbnZtZTBuMXAyIGFuZCAvZGV2L252bWUwbjFwMyByZXNwZWN0aXZl bHkgKGFzIG91dHB1dHRlZCBieSBibGtpZCkuCkdSVUJfQ01ETElORV9MSU5VWCBjb250YWlucyB0 aGUgY29ycmVjdCBjcnlwdGRldmljZSBwYXJhbWV0ZXJzIGZvciBib3RoIHBhcnRpdGlvbnMsIGFs c28gd2l0aCBVVUlEcy4KCkkgY2hlY2tlZCB0aGUgaW5pdHJhbWZzIGNvbnRlbnRzIHVzaW5nICd1 bm1raW5pdHJhbWZzJyBpbiAvdG1wL2luaXRyYW1mcy8gdG8gcmV2aWV3IG1haW4vY3J5cHRyb290 L2NyeXB0dGFiLCBidXQgaXQgb25seSBjb250YWlucyBhbiBlbnRyeSBmb3IgbHZtX2NyeXB0LCBi b290X2NyeXB0IGlzIG1pc3NpbmcuClRoYXQgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IGFmdGVy IEdSVUIgaGFuZHMgb2ZmIGNvbnRyb2wgdG8gdGhlIGtlcm5lbCwgdGhlIGJvb3RfY3J5cHQgbWFw cGluZyBpcyBsb3N0LgpTeXN0ZW1kIHRoZW4gYXR0ZW1wdHMgdG8gZGVjcnlwdCBib290X2NyeXB0 IGFnYWluLgoKVGhpbmdzIEkgYXR0ZW1wdGVkOgoxLiBTeXN0ZW1kIHVuaXQgb3ZlcnJpZGVzIHRv IHByZXZlbnQgdGhlIHNlY29uZCBkZWNyeXB0aW9uCjIuIE1vdmluZyB0aGUgYm9vdF9jcnlwdCBl bnRyeSB0byB0aGUgZmlyc3QgbGluZSBpbiBjcnlwdHRhYiwganVzdCBpbiBjYXNlIHRoZSBjcnlw dHJvb3QgaG9vayBsb2NhdGVkIGF0IC91c3Ivc2hhcmUvaW5pdHJhbWZzLXRvb2xzL2hvb2tzL2Ny eXB0cm9vdCBwcm9jZXNzZXMgb25seSB0aGUgZmlyc3QgZW50cnkuIE9mIGNvdXJzZSwgdGhhdCBk aWRuJ3QgZG8gYW55dGhpbmcgLSBEZWJpYW4gaXMgcHJldHR5IHN0YWJsZSBhZnRlciBhbGwuCjMu IFZhcmlvdXMgaW5pdHJhbWZzIGNvbmZpZ3VyYXRpb24gYXR0ZW1wdHMKCkV2ZXJ5IHRpbWUgYWZ0 ZXIgbWFraW5nIGNoYW5nZXMsIEkgZXhlY3V0ZWQ6CnVwZGF0ZS1pbml0cmFtZnMgLXUgLWsgYWxs CmdydWItaW5zdGFsbCAtLXRhcmdldD14ODZfNjQtZWZpIC0tZWZpLWRpcmVjdG9yeT0vZWZpIChJ IGRlbGV0ZWQgbXkgb2xkIC9ib290L2VmaSBmb2xkZXIgYW5kIHJlbWFwcGVkIHRoZSAvZGV2L252 bWUwbjFwMSBkZXZpY2UgdG8gL2VmaSBpbiAvZXRjL2ZzdGFiIGFuZCBhcyBmYXIgYXMgSSBjYW4g c2VlLCBpdCB3b3JrcyBmaW5lKQp1cGRhdGUtZ3J1YgpyZWJvb3Qgbm93CgpWZXJ5LCB2ZXJ5IG9m dGVuLCBteSBjaGFuZ2VzIHJlc3VsdGVkIGVpdGhlciBpbiB0aW1lb3V0cyBhbmQgL2Jvb3Qgbm90 IGJlaW5nIG1vdW50ZWQsIG9yIHRoZSBvdmVycmlkZXMgbm90IHdvcmtpbmcuCgpTbyBoZXJlIGFy ZSBzb21lIHF1ZXN0aW9ucyBJIG5lZWQgaGVscCB3aXRoOgoxLiBXaHkgaXNuJ3QgYSBjcnlwdHRh YiBlbnRyeSBmb3IgYm9vdF9jcnlwdCBpbmNsdWRlZCBpbiB0aGUgaW5pdHJhbWZzPwoyLiBJcyB0 aGVyZSBhIHJlY29tbWVuZGVkIHdheSB0byBwcmVzZXJ2ZSB0aGUgZGV2aWNlIG1hcHBpbmcgZnJv bSBHUlVCPwozLiBJcyB0aGlzIHNldHVwIGV2ZW4gc3VwcG9ydGVkL3JlY29tbWVuZGVkPwoKU3lz dGVtIGRldGFpbHM6Cktlcm5lbDogNi4xLjAtMzAtYW1kNjQKRGViaWFuIHZlcnNpb246IDYuMS4x MjQtMSAoMjAyNS0wMS0xMikgeDg2XzY0IEdOVS9MaW51eAonZHBrZyAtbCB8IGdyZXAgLUUgImdy dWJ8Y3J5cHRzZXR1cCIgb3V0cHV0cyB0aGUgZm9sbG93aW5nIHBhY2tldHM6CmNyeXB0c2V0dXAs IGNyeXB0c2V0dXAtYmluLCBjcnlwdHNldHVwLWluaXRyYW1mcywgZ3J1Yi1jb21tb24sIGdydWIt ZWZpLWFtZDY0LCBncnViLWVmaS1hbWQ2NC1iaW4sIGdydWItZWZpLWFtZDY0LXNpZ25lZCwgZ3J1 YjItY29tbW9uIGFuZCBsaWJjcnlwdHNldHVwMTI6YW1kNjQKCkkgcmVhbGx5IGhvcGUgeW91IGNh biBoZWxwIG1lLgpCZXN0IHJlZ2FyZHMsCkF1dG9tw6Z0aWM=

PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0 cHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwg MjU1KTsiPjxzcGFuPkhpLDwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4+PGJyPjwvc3Bhbj48L2Rp dj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+PHNwYW4+PHNwYW4+SSdtIGNvbmZpZ3VyaW5nIGEgbmV3IERlYmlhbiBpbnN0YWxs YXRpb24gb24gbXkgd29ya3N0YXRpb24sIHdpdGggYm90aCB0aGUgL2Jvb3QgcGFydGl0aW9uIGFu ZCB0aGUgcm9vdCBmaWxlc3lzdGVtIGVuY3J5cHRlZDo8L3NwYW4+PC9zcGFuPjwvZGl2PjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyBj b2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7 Ij48c3Bhbj48c3Bhbj4tIC9kZXYvbnZtZTBuMXAxIC0mZ3Q7IC9FRkk8YnI+PC9zcGFuPjxkaXY+ PHNwYW4+LSAvZGV2L252bWUwbjFwMiAtJmd0OyBMVUtTMiAocGJrZGYyKSAtJmd0OyAvYm9vdDwv c3Bhbj48L2Rpdj48ZGl2PjxzcGFuPi0gL2Rldi9udm1lMG4xcDMgLSZndDsgTFVLUzIgLSZndDsg TFZNIGNvbnRhaW5pbmcgcm9vdCBhbmQgb3RoZXIgdm9sdW1lczwvc3Bhbj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PjxzcGFuPlRoZSBzeXN0ZW0gYm9vdHMsIGJ1dCByZXF1aXJlcyBlbnRlcmlu ZyB0aGUgL2Jvb3QgcGFzc3dvcmQgdHdpY2U6PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+PHNwYW4+ T25jZSBmb3IgR1JVQiwgYW5kIG9uY2UgYWdhaW4gZHVyaW5nIHN5c3RlbWQgaW5pdGlhbGl6YXRp b24uPC9zcGFuPjxicj48L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bhbj5Cb3Ro IGRldmljZXMgYXJlIHByb3Blcmx5IGNvbmZpZ3VyZWQgaW4gL2V0Yy9jcnlwdHRhYiB3aXRoIHRo ZSBVVUlEcyBmb3IgL2Rldi9udm1lMG4xcDIgYW5kIC9kZXYvbnZtZTBuMXAzIHJlc3BlY3RpdmVs eSAoYXMgb3V0cHV0dGVkIGJ5IGJsa2lkKS48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+R1JV Ql9DTURMSU5FX0xJTlVYIGNvbnRhaW5zIHRoZSBjb3JyZWN0IGNyeXB0ZGV2aWNlIHBhcmFtZXRl cnMgZm9yIGJvdGggcGFydGl0aW9ucywgYWxzbyB3aXRoIFVVSURzLjxicj48L3NwYW4+PC9kaXY+ PGRpdj48c3Bhbj48YnI+PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+SSBjaGVja2VkIHRoZSBpbml0 cmFtZnMgY29udGVudHMgdXNpbmcgJ3VubWtpbml0cmFtZnMnIGluIC90bXAvaW5pdHJhbWZzLyB0 byByZXZpZXcgbWFpbi9jcnlwdHJvb3QvY3J5cHR0YWIsIGJ1dCBpdCBvbmx5IGNvbnRhaW5zIGFu IGVudHJ5IGZvciBsdm1fY3J5cHQsIGJvb3RfY3J5cHQgaXMgbWlzc2luZy48L3NwYW4+PC9kaXY+ PGRpdj48c3Bhbj5UaGF0IGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCBhZnRlciBHUlVCIGhhbmRz IG9mZiBjb250cm9sIHRvIHRoZSBrZXJuZWwsIHRoZSBib290X2NyeXB0IG1hcHBpbmcgaXMgbG9z dC48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5TeXN0ZW1kIHRoZW4gYXR0ZW1wdHMgdG8gZGVjcnlw dCBib290X2NyeXB0IGFnYWluLjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxzcGFu PlRoaW5ncyBJIGF0dGVtcHRlZDo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4xLiBTeXN0ZW1kIHVu aXQgb3ZlcnJpZGVzIHRvIHByZXZlbnQgdGhlIHNlY29uZCBkZWNyeXB0aW9uPGJyPjwvc3Bhbj48 L2Rpdj48ZGl2PjxzcGFuPjIuIE1vdmluZyB0aGUgYm9vdF9jcnlwdCBlbnRyeSB0byB0aGUgZmly c3QgbGluZSBpbiBjcnlwdHRhYiwganVzdCBpbiBjYXNlIHRoZSBjcnlwdHJvb3QgaG9vayBsb2Nh dGVkIGF0IDxzcGFuPi91c3Ivc2hhcmUvaW5pdHJhbWZzLXRvb2xzL2hvb2tzL2NyeXB0cm9vdDwv c3Bhbj4gcHJvY2Vzc2VzIG9ubHkgdGhlIGZpcnN0IGVudHJ5LiBPZiBjb3Vyc2UsIHRoYXQgZGlk bid0IGRvIGFueXRoaW5nIC0gRGViaWFuIGlzIHByZXR0eSBzdGFibGUgYWZ0ZXIgYWxsLjxicj48 L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj4zLiBWYXJpb3VzIGluaXRyYW1mcyBjb25maWd1cmF0aW9u IGF0dGVtcHRzPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2Pjxz cGFuPkV2ZXJ5IHRpbWUgYWZ0ZXIgbWFraW5nIGNoYW5nZXMsIEkgZXhlY3V0ZWQ6PC9zcGFuPjwv ZGl2PjxkaXY+PHNwYW4+dXBkYXRlLWluaXRyYW1mcyAtdSAtayBhbGw8L3NwYW4+PC9kaXY+PGRp dj48c3Bhbj5ncnViLWluc3RhbGwgLS10YXJnZXQ9eDg2XzY0LWVmaSAtLWVmaS1kaXJlY3Rvcnk9 L2VmaSAoSSBkZWxldGVkIG15IG9sZCAvYm9vdC9lZmkgZm9sZGVyIGFuZCByZW1hcHBlZCB0aGUg L2Rldi9udm1lMG4xcDEgZGV2aWNlIHRvIC9lZmkgaW4gL2V0Yy9mc3RhYiBhbmQgYXMgZmFyIGFz IEkgY2FuIHNlZSwgaXQgd29ya3MgZmluZSk8YnI+PC9zcGFuPjwvZGl2PjxkaXY+dXBkYXRlLWdy dWI8L2Rpdj48ZGl2PnJlYm9vdCBub3c8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5WZXJ5 LCB2ZXJ5IG9mdGVuLCBteSBjaGFuZ2VzPHNwYW4+PHNwYW4+IHJlc3VsdGVkIGVpdGhlciBpbiB0 aW1lb3V0cyBhbmQgL2Jvb3Qgbm90IGJlaW5nIG1vdW50ZWQsIG9yIHRoZSBvdmVycmlkZXMgbm90 IHdvcmtpbmc8L3NwYW4+PC9zcGFuPi48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bh bj5TbyBoZXJlIGFyZSBzb21lIHF1ZXN0aW9ucyBJIG5lZWQgaGVscCB3aXRoOjwvc3Bhbj48L2Rp dj48ZGl2PjxzcGFuPjEuIFdoeSBpc24ndCBhIGNyeXB0dGFiIGVudHJ5IGZvciBib290X2NyeXB0 IGluY2x1ZGVkIGluIHRoZSBpbml0cmFtZnM/IDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPjIuIElz IHRoZXJlIGEgcmVjb21tZW5kZWQgd2F5IHRvIHByZXNlcnZlIHRoZSBkZXZpY2UgbWFwcGluZyBm cm9tIEdSVUI/PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+My4gSXMgdGhpcyBzZXR1cCBldmVuIHN1 cHBvcnRlZC9yZWNvbW1lbmRlZD88L3NwYW4+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48c3Bh bj5TeXN0ZW0gZGV0YWlsczo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5LZXJuZWw6IDYuMS4wLTMw LWFtZDY0PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4+RGViaWFuIHZlcnNpb246IDYuMS4xMjQtMSAo MjAyNS0wMS0xMikgeDg2XzY0IEdOVS9MaW51eDwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPidkcGtn IC1sIHwgZ3JlcCAtRSAiZ3J1YnxjcnlwdHNldHVwIiBvdXRwdXRzIHRoZSBmb2xsb3dpbmcgcGFj a2V0czo8L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj5jcnlwdHNldHVwLCBjcnlwdHNldHVwLWJpbiwg Y3J5cHRzZXR1cC1pbml0cmFtZnMsIGdydWItY29tbW9uLCBncnViLWVmaS1hbWQ2NCwgPHNwYW4+ PHNwYW4+Z3J1Yi1lZmktYW1kNjQ8L3NwYW4+PC9zcGFuPi1iaW4sIDxzcGFuPjxzcGFuPmdydWIt ZWZpLWFtZDY0PC9zcGFuPjwvc3Bhbj4tc2lnbmVkLCBncnViMi1jb21tb24gYW5kIGxpYmNyeXB0 c2V0dXAxMjphbWQ2NDxicj48L3NwYW4+PC9kaXY+PGRpdj48c3Bhbj48YnI+PC9zcGFuPjwvZGl2 PjxkaXY+PHNwYW4+PGJyPjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkkgcmVhbGx5IGhvcGUgeW91 IGNhbiBoZWxwIG1lLjwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuPkJlc3QgcmVnYXJkcyw8L3NwYW4+ PC9kaXY+PGRpdj48c3Bhbj5BdXRvbcOmdGljPGJyPjwvc3Bhbj48L2Rpdj48L3NwYW4+PC9kaXY+

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Feb 04, 2025 at 12:18:10AM -0800, Loren M. Lang wrote:

On Mon, Feb 03, 2025 at 10:39:25PM +0000, Automætic wrote:

Hi,

I'm configuring a new Debian installation on my workstation, with both the /boot partition and the root filesystem encrypted:
- /dev/nvme0n1p1 -> /EFI
- /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
- /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes

The system boots, but requires entering the /boot password twice:
Once for GRUB, and once again during systemd initialization.

I think the solution is to not encrypt the /boot partition. That
partition shouldn't contain anything sensitive on it anyways [...]

That's what I do currently, but to be fair, this exposes you to
someone replacing your boot kit by something else (which could,
for example, record your passphrase and pass it on).

This can also, of course, be mitigated by some secure boot schema
(provided you control your BIOS -- most of the time it's someone
else, anyway ;-)

This has been known by the (somewhat sexist) term "Evil Maid
Attack" [1].

It all depends on the threat model(s) you start from.

Cheers

[1] https://en.wikipedia.org/wiki/Evil_Maid_attack
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ6HVLQAKCRAFyCz1etHa RqwhAJ9YluUHzNBNRG1SfvVNQIzSysRqdACfQP2uB858M1BO+JPX6GSpxMBy/rc=
=+lHZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Feb 03, 2025 at 10:39:25PM +0000, Automætic wrote:

Hi,

I'm configuring a new Debian installation on my workstation, with both the /boot partition and the root filesystem encrypted:
- /dev/nvme0n1p1 -> /EFI
- /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
- /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes

The system boots, but requires entering the /boot password twice:
Once for GRUB, and once again during systemd initialization.

I think the solution is to not encrypt the /boot partition. That
partition shouldn't contain anything sensitive on it anyways. In order
to avoid decrypting it twice, there would need to be some mechanism for
GRUB to pass the encryption information through to the Linux kernel
system or initrd environment and I am not aware of any such mechanism.
GRUB passes the kernel command-line which is public and visible under /proc/cmdline, details on the initrd that was loaded, and a few other parameters like memory size and video mode, but there's no standard way
to pass extra details like crypto keys that need to be kept secret.

With that said, don't take my word for it as I may not be completely
informed. However, I don't think it'll likely be worth the effort,
especially when things go wrong. I did take a look at the GRUB 2 source
code and discovered some support for an MBR-encrypted by TrueCrypt, but
it seems to be strongly linked with some kind of El Torito CD-ROM boot
image and is likely more complex than is worth it. Feel free to prove my earlier assertion wrong. :-)

-Loren

Both devices are properly configured in /etc/crypttab with the UUIDs for /dev/nvme0n1p2 and /dev/nvme0n1p3 respectively (as outputted by blkid).
GRUB_CMDLINE_LINUX contains the correct cryptdevice parameters for both partitions, also with UUIDs.

I checked the initramfs contents using 'unmkinitramfs' in /tmp/initramfs/ to review main/cryptroot/crypttab, but it only contains an entry for lvm_crypt, boot_crypt is missing.
That leads me to believe that after GRUB hands off control to the kernel, the boot_crypt mapping is lost.
Systemd then attempts to decrypt boot_crypt again.

Things I attempted:
1. Systemd unit overrides to prevent the second decryption
2. Moving the boot_crypt entry to the first line in crypttab, just in case the cryptroot hook located at /usr/share/initramfs-tools/hooks/cryptroot processes only the first entry. Of course, that didn't do anything - Debian is pretty stable after all.
3. Various initramfs configuration attempts

Every time after making changes, I executed:
update-initramfs -u -k all
grub-install --target=x86_64-efi --efi-directory=/efi (I deleted my old /boot/efi folder and remapped the /dev/nvme0n1p1 device to /efi in /etc/fstab and as far as I can see, it works fine)
update-grub
reboot now

Very, very often, my changes resulted either in timeouts and /boot not being mounted, or the overrides not working.

So here are some questions I need help with:
1. Why isn't a crypttab entry for boot_crypt included in the initramfs?
2. Is there a recommended way to preserve the device mapping from GRUB?
3. Is this setup even supported/recommended?

System details:
Kernel: 6.1.0-30-amd64
Debian version: 6.1.124-1 (2025-01-12) x86_64 GNU/Linux
'dpkg -l | grep -E "grub|cryptsetup" outputs the following packets: cryptsetup, cryptsetup-bin, cryptsetup-initramfs, grub-common, grub-efi-amd64, grub-efi-amd64-bin, grub-efi-amd64-signed, grub2-common and libcryptsetup12:amd64

I really hope you can help me.
Best regards,
Automætic

--
Loren M. Lang
lorenl@north-winds.org
http://www.north-winds.org/
IRC: penguin359


Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA

-----BEGIN PGP SIGNATURE-----

iHUEABEIAB0WIQT3wmbBr9cpdt12HlPMe9wUn2Md1wUCZ6HNPQAKCRDMe9wUn2Md 1yu6AQDs7I0NaY9o0R9PRIyf7iURwAIrMHuaG9yN/kwsZT+9XQD5AY1P3AhT6YLD fxJlM9hy2d4bPbJz9Y9yPiKeyrEFcJY=
=iCTQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Feb 04, 2025 at 09:52:03AM +0100, tomas@tuxteam.de wrote:

On Tue, Feb 04, 2025 at 12:18:10AM -0800, Loren M. Lang wrote:

On Mon, Feb 03, 2025 at 10:39:25PM +0000, Automætic wrote:

Hi,

I'm configuring a new Debian installation on my workstation, with both the /boot partition and the root filesystem encrypted:
- /dev/nvme0n1p1 -> /EFI
- /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
- /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes

The system boots, but requires entering the /boot password twice:
Once for GRUB, and once again during systemd initialization.

I think the solution is to not encrypt the /boot partition. That
partition shouldn't contain anything sensitive on it anyways [...]

That's what I do currently, but to be fair, this exposes you to
someone replacing your boot kit by something else (which could,
for example, record your passphrase and pass it on).

I don't see how this actually adds any security because it will be GRUB
that needs to first ask you for your passphrase and it will be the GRUB
that was loaded from your unencrpyted EFI partition. You've just moved
the goal post on step earlier in the boot process. Without Secure Boot
and possibly some use of the TPM, you can't protect against that.

Now, if the concern is that something might modify the /boot partition
while the OS is loaded then you probably don't want /boot mounted
anyways after GRUB decrypts it and grabs the kernel/initrd/config it
needs. However, you are also already compromised by that point anyways.

/boot should be about as sensitive as EFI is in this model and Secure
Boot can protect both by following the standard chain of signatures for
each file it loads.

This can also, of course, be mitigated by some secure boot schema
(provided you control your BIOS -- most of the time it's someone
else, anyway ;-)

This has been known by the (somewhat sexist) term "Evil Maid
Attack" [1].

It all depends on the threat model(s) you start from.

Cheers

[1] https://en.wikipedia.org/wiki/Evil_Maid_attack
--
t

--
Loren M. Lang
lorenl@north-winds.org
http://www.north-winds.org/
IRC: penguin359


Public Key: http://www.north-winds.org/lorenl_pubkey.asc
Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA

-----BEGIN PGP SIGNATURE-----

iHUEABEIAB0WIQT3wmbBr9cpdt12HlPMe9wUn2Md1wUCZ6HcfQAKCRDMe9wUn2Md 16gOAQDDg5vGLQpKGfugjtIH93Hb4iGWs1JlXZhRhDngc9AgNQEA3sHvqCyrmsbm CX74y/WI7o49rlvhrrbaAuWystCEo2g=
=bAQj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-02-03, Automætic wrote:

Both devices are properly configured in /etc/crypttab with the UUIDs
for /dev/nvme0n1p2 and /dev/nvme0n1p3 respectively (as outputted by
blkid).

You set this manually ?

I checked the initramfs contents using 'unmkinitramfs' in
/tmp/initramfs/ to review main/cryptroot/crypttab, but it only contains
an entry for lvm_crypt, boot_crypt is missing.

It seems the right way as initrd is loaded from /boot which is already unencrypted. And this is why update-initramfs filters your /etc/crypttab
and puts only root fs in initrd /cryptroot/crypttab. To avoid asking a
second password after initrd, you could use a key file in your
/etc/crypttab.

I don't know much about grub but it could set a different mapping from
what you set in /etc/fstab. If you really want to investigate if this
mapping is up during initrd, you could add a script in /etc/initramfs-tools/scripts/init-premount with something like :

#!/bin/sh

# initramfs magic

PREREQ=""
prereqs()
{
echo "$PREREQ"
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac

echo "sourcing initramfs functions"
. /scripts/functions

# Begin real processing below this line

blkid >> /run/initramfs/my.log
mount >> /run/initramfs/my.log

Run update-initramfs and after booting you should get logs in /run/initramfs/my.log

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2/3/25 23:39, Automætic wrote:

Hi,

I'm configuring a new Debian installation on my workstation, with both the /boot partition and the root filesystem encrypted:
- /dev/nvme0n1p1 -> /EFI
- /dev/nvme0n1p2 -> LUKS2 (pbkdf2) -> /boot
- /dev/nvme0n1p3 -> LUKS2 -> LVM containing root and other volumes

The system boots, but requires entering the /boot password twice:
Once for GRUB, and once again during systemd initialization.

3. Is this setup even supported/recommended?

The only way that I found is to use keyfile:

( umask 0077 && dd if=/dev/urandom bs=1 count=64
of=/etc/keys/boot.key conv=excl,fsync ) || exit $?
cryptsetup luksAddKey /dev/${DEVICE_NAME} /etc/keys/boot.key --key-slot=1 || exit $?
sed -i "/${DEVICE_NAME}_crypt/s/[^ ]*/\/etc\/keys\/boot.key/3;/${DEVICE_NAME}_crypt/s/[^ ]*/key-slot=1/4" /etc/crypttab || exit $?
chmod 0644 /etc/crypttab || exit $?

Note that this e-mail might be folded by my mailer.

--
John Doe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)