search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.41k stars 185 forks source link

Measuring PCI devices. #704

Open Tonux599 opened 4 years ago

Tonux599 commented 4 years ago

Is this a desired feature? My knowledge on how heads does its measurements is minimal however if the output of ‘lspci -v’ can be measured the user would be informed via TOTP if their hardware has changed. Again I’m not sure of the attack surface here however off the top of my head an attacker could, for example, replace Mini-PCIe wireless card with a malicious one.

tlaurion commented 4 years ago

I’m not sure of the attack surface here however off the top of my head an attacker could, for example, replace Mini-PCIe wireless card with a malicious one.

@Tonux599 : for which no driver would be loaded inside of Heads. But why not. Simple to implement!

Tonux599 commented 4 years ago

Is there an appetite for this? Heads does a good job at verifying the integrity of the bootrom with the user but is further verifying the integrity of the system components a goal?

tlaurion commented 4 years ago

@Tonux599 : gave a little bit of thought to that idea and there are two different things happening under heads 1- Measurement of CBFS parts are done in romstage of coreboot under 4.8.1 with applied patches. This is before raminit, before even having a kernel launched or whatever else. This permits to take those measurements with TPM 2- The second stage of measurements is happening at boot time, against /boot digest, signed with user's private key inside of USB Security dongle and verified against public key inserted in the rom, measured with TPM in PCR7 and combined with LUKS header when using Disk Unlock Key if a default boot is configured.

@Tonux599 : where would you see this happening?

Tonux599 commented 4 years ago

@tlaurion I think it depends on whether a malicious PCI device could attack the system in anyway even if the kernel modules were not loaded. If we can be sure it could not, then I think option 2 would be acceptable (This will be super easy to implement also as we could just cat the output of lspci -v to a file in /boot). On any (intended) changes to the systems PCI devices the user would have to take the same route as if they had updated their initrd or grub configs.

However, if it is deemed that a malicious PCI device could attack the system in some way without kernel modules loaded, I think option 1 would be more appropriate.

tlaurion commented 4 years ago

@Tonux599 : I am not sure we have anything ready to use to take those measurements in romstage but cbmem used memory space for logging of discovered pciids?

arhabd commented 2 weeks ago

just wanted to say i would love to see this