Hi!
An user have /home in a different encrypted partition via pcrlock. After
the initrd, during the normal boot process, the systemd-cryptsetup
generator is reading this file to open the devices in /dev/mapper/$name.
But this is happening before /var gets mounted, and this contains the
pcrloc
On 2025-03-14 08:26, Andrei Borzenkov wrote:
I would like to see a solution that can be enabled by default for an
average non-technical user. Both your solution and upstream PR
effectively lock users out if something goes wrong. This may be
appropriate for a standalone appliance, but for a commo
On 2025-03-10 08:41, Andrei Borzenkov wrote:
On Mon, Mar 10, 2025 at 11:03 AM aplanas wrote:
On 2025-03-08 18:52, Diorcet Yann wrote:
> - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
> from the "good" root partition
This is done by "system
On 2025-03-10 18:25, Diorcet Yann wrote:
Le 10/03/2025 à 17:27, Adrian Vovk a écrit :
2) Just before opening the var LUKS:
PCR15=0 or something predictable
cryptsetup is used to open var and update PCR15 thanks to
tpm2-measure-pcr=yes. but in this case /dev/sda1 is replaced with the
original
On 2025-03-10 23:32, Demi Marie Obenour wrote:
On Mon, Mar 10, 2025 at 09:10:59PM +, aplanas wrote:
[...]
> Detecting the situation and causing boot to fail, as described above,
> would
> force the attacker to not only DOS the TPM but actually completely MITM
> it.
> Is th
ervice that stop the boot process if the expected value
did not match
(also validate the signature of the file that contains the prediction)
https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.sh
* (Only for non-UKIs) A service that import into the initrd the
prediction
On 2025-03-10 19:04, Adrian Vovk wrote:
Presuming a system like this:
- We've got a Linux desktop system
- We have two dm-verity protected /usr partitions
- We have one encrypted rootfs
- We're using systemd-repart to create the rootfs on first boot
- The rootfs is automatically unlocked by the
On 2025-03-13 10:10, Andrei Borzenkov wrote:
On Tue, Mar 11, 2025 at 12:17 AM aplanas wrote:
[1]
https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/
This attack is possible because root is bound to the boot time TPM
state that is not modified after the system is booted
On 2025-05-09 13:03, Lennart Poettering wrote:
On Fr, 09.05.25 15:58, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> If you want explicit config use the simpler PCR protections
> systemd-cryptsetup gives you, and avoid pcrlock.
I obviously want to use pcrlock to have alternatives (like being
On 2025-05-09 12:36, Andrei Borzenkov wrote:
I know that it is documented, but that leads to rather bad user
experience. User requests specific protection via --pcr= option,
pcrlock decides to skip (some of) them and binds unlocking to just a
subset of PCRs pretending that the operation succeeded
10 matches
Mail list logo
