lpc/future-of-platform-security-measurement.md: init #59
Conversation
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
|
|
||
| # Intel Boot Guard and Management Engine | ||
|
|
||
| Alternative ways of checking the failing checks |
There was a problem hiding this comment.
My answer always was: Dasharo/coreboot#453
Even vendor BIOS exposes ME status in SMBIOS, so making coreboot do the same would only help generalize the checks.
If fwupd detects there is no ME in the system, it could look at SMBIOS to read out the status.
There was a problem hiding this comment.
I have checked some our log dumps from various hardware platforms against this. Proposed such an approach in linked fwupd issue: fwupd/fwupd#6011 (comment)
There was a problem hiding this comment.
This also means that we would not need any support from kernel here, so this makes it perhaps less interesting as LPC problem.
There was a problem hiding this comment.
This has been heavily changed since then. This IBG/ME problem seems not really critical one for LPC. We are working on it in the linked issue.
Moved it to backup slides.
| Key Hash Exposure: Critical for Modern Security | ||
|
|
||
| Current Problem: | ||
| - BootGuard Key Manifest is in SPI flash, complex to parse |
There was a problem hiding this comment.
Or in the fuses. Fuses are unreadable if ME disabled.
| + Control-flow enforcement technology | ||
|
|
||
| <!-- | ||
| --> |
There was a problem hiding this comment.
There is no need to talk so much about HSI. We should refer to materials and introduce them as briefly as possible so our story/narration can continue with a correct minimal background.
There was a problem hiding this comment.
Slight more reduced in: 27e7491
I plan to quickly go through this and keep something in slide for completeness
| | <span style="color: green;">Intel BootGuard: Verified</span> | <span style="color: green;">HFSTS6</span> | <span style="color: green;">N/A</span> | | ||
| | <span style="color: green;">Intel BootGuard: ACM</span> | <span style="color: green;">HFSTS6</span> | <span style="color: green;">HFSTS5</span> | | ||
| | <span style="color: green;">Intel BootGuard: Policy</span> | <span style="color: green;">HFSTS6</span> | <span style="color: green;">N/A</span> | | ||
| | <span style="color: red;">Intel BootGuard: OTP fuse</span> | <span style="color: red;">HFSTS6</span> | <span style="color: red;">HFSTS6</span> | |
There was a problem hiding this comment.
There is a lot of space in that table. Is there a way to make the font bigger? I tried at some point, but didn't have time to complete that task.
There was a problem hiding this comment.
I will look in to it if the table stays. But right now it seems we are going into SMBIOS path, and raising this on LPC might not be needed (we have solution, we do not have a kernel-related problem).
There was a problem hiding this comment.
This table is removed: 27e7491
Another table is there. Something like this did the trick:
<style>
th {
font-size: 1.1em !important;
font-weight: bold !important;
}
td {
font-size: 0.8em !important;
}
</style>
| │ │ └── arm_xyz/ | ||
| │ └── status # "active", "disabled", "not_provisioned" | ||
| ├── drtm/ # Vendor-agnostic HRoT interface | ||
| ``` |
There was a problem hiding this comment.
This is bold move. Whole problem is really hard so I would really wonder what people would say.
There was a problem hiding this comment.
I agree. Do you have any other suggestions on how kernel can help us with HSI, or similar approaches to assess platform's security?
There was a problem hiding this comment.
The only way that came to my mind requires looking deeply at how other operating systems provide that information and how much it involves the kernel.
There are multiple things which could be verified more comprehensively, maybe those are to some extent:
- TPM - all details, right now I'm not sure if all information about TPM is exposed, but maybe that is not a kernel role, but some user space if the kernel device is exposed
- UEFI Secure Boot status has to be deducted from variables, and can also be covered by an application like
sbctl. - Windows requires WSMT for SMM security, which is part of ACPI: https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-system-description-tables#windows-smm-security-mitigations-table-wsmt - nota Linux thing, but the question is if that information is exposed and can be correctly consumed and validated - VBS features rely on it Windows 11 VBS (Virtualization-based Security) appears Not enabled on System Information Dasharo/dasharo-issues#539, https://github.com/tianocore/edk2/issues?q=is%3Aissue%20state%3Aclosed%20WSMT
- OEM VBS: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs
a. Unified Extensible Firmware Interface (UEFI) Memory Reporting
b. MOR: https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/device-guard-requirements
There was a problem hiding this comment.
I went through more details on how existing measurements are made and reworked this by providing some suggestions: 27e7491
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
… slides Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
1st version.
To do: