I get a red "Not found" for IOMMU when in reality it should say "Disabled" or "Supported but disabled

How do we know if the IOMMU is supported but disabled?

it should be enabled by adding intel_iommu=on to the kernel cmdline arguments

I think this is the kind of thing we can add to https://github.com/fwupd/fwupd/blob/master/docs/hsi.xml -- the GNOME Firmware client will have clickable links on the failures to that document eventually.

which means fwupdmgr would have to what grep for SHSTK from a readelf output

Yep, we do that: https://github.com/fwupd/fwupd/blob/master/plugins/cpu/fu-cpu-helper-cet.c

lacks suggestions for security improvements for the negative values in the report ( The red's ).

I would mention that by design some of these items are not fixable by an end user, but that they are showing the implied security put into the platform and firmware that the OS process can see.

Some things like pre-boot DMA protection can be enabled by the BIOS. If that's enabled, it will automatically turn it on in the kernel as well at runtime.

For consistency I would say that all enabled/disabled be replaced with "Supported and enabled" and "Supported but disabled" which makes them align with "Not supported" and just get rid of "Found" and "Not found" from the report. for example the "TPM v2.0: Found" tells the end user nothing Is it found and enabled ( which makes it "Supported and enabled" ) or is it Found and disabled ( which makes it "Supported but disabled" ) then there is the question for whom this information is for, as in is the vendor suppose to take action, the distribution or the end user or to put it differently now that the information has been gathered and used in a report. how is that information expected to be used and in what purpose?

I get a red "Not found" for IOMMU when in reality it should say "Disabled" or "Supported but disabled

How do we know if the IOMMU is supported but disabled?

Hmm qemu might have some vodoo to properly check for this but I would think if the presence of vmx ( intel ) or svm ( amd ) in /proc/cpuinfo should tell if it's supported ( by the hw ) or not and if true and /sys/class/iommu/ is empty it's "Supported but disabled", if it's true and /sys/class/iommu/ is populated ( there should exist dmarX symbolic link pointing /sys/devices/virtual/iommu/dmarX ) then it's "Supported and enabled"

Tainted and untainted should probably be swapped out for something like modified/unmodified which is a term end users are probably more familiar with.

whom this information is for, as in is the vendor suppose to take action

Other than runtime HSI, they are mostly things that either OS vendor, platform vendor, or BIOS vendor may need to change.

vmx or svm

So VMX means the CPU is capable of using an IOMMU? Is there more from a platform point of view than having a CPU with VMX support to actually use the IOMMU? I'll admit i'm not sure where the IOMMU is actually found, e.g. in the CPU die or elsewhere.

VMX means it supports virtualization instructions, it doesn't mean that VTd specifically is supported.

If I can recall correctly if the Intel processor supported virtualization it had VT-d capability however motherboard manufacturers simply decided to disable the user ability to modify the setting ( as in the ability to enabled it ) within BIOS which brings up another problem there is no reliable way to determine if it has or can be enabled in the bios. I suppose it's probably simply best to ping the virt devs and see how they are determining this and emulate that then atleast it is as good ( or bad ) as they are determining it.

This comes back to the point of HSI though - is it for users to try to improve their security score? Or is it for manufactures and OS vendors to improve security of their platform and stack. Anything outside of run-time I realistically don't think users should do anything.

I don't think it's worth over engineering the design of catching cases that there might be an iommu but it's not enabled.

We're trying to cover the case that someone buys a laptop with Linux preinstalled or someone installs a popular distro. Measure the security of those, and if the scores are poor someone got something wrong along the way.

OEMs should ship with pre boot DMA protection enabled and the linux kernel will enable the IOMMU at runtime. If it shows as a red we can bury some text in the help page that says what to look for to enable in your BIOS in case you actively decided to turn it off.

This comes back to the point of HSI though - is it for users to try to improve their security score? Or is it for manufactures and OS vendors to improve security of their platform and stack. Anything outside of run-time I realistically don't think users should do anything.

I don't think it's worth over engineering the design of catching cases that there might be an iommu but it's not enabled.

Right which is why I thought simply checking for the presence of vmx ( intel ) or svm ( amd ) would be good enough until proven otherwise solution without the risk of going down a rabbit hole in one form or another chasing that.

We're trying to cover the case that someone buys a laptop with Linux preinstalled or someone installs a popular distro. Measure the security of those, and if the scores are poor someone got something wrong along the way.

OEMs should ship with pre boot DMA protection enabled and the linux kernel will enable the IOMMU at runtime. If it shows as a red we can bury some text in the help page that says what to look for to enable in your BIOS in case you actively decided to turn it off.

Manufactures are already doing that under the Microsoft's Secured Core computer [1][2] banner arguably an collaboration you guys should be part of and be sponsored for.

Regarding the help page, due to fragmentation in the linux ecosystem and a lack of equivalent of "Window Security Guard" application in the desktop environments, where would you suggest such an help page should reside?

The distribution documentation ( Fedora ), the desktop environment ( upstream Gnome/KDE documentation ) or where the code resides ( github )?

1. https://www.microsoft.com/en-us/windowsforbusiness/windows10-secured-core-computers
2. https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-kernel-dma-protection

where would you suggest such an help page should reside

My gut instinct says in the hsi.xml specification page.

Testing out the new security feature and have some pointers.

λ ~ » sudo fwupdmgr security --force | grep swap
✘ Linux swap:                    Unencrypted

And I assume it thinks unencrypted because /proc/swap has a file:

λ ~ » cat /proc/swaps 
Filename				Type		Size		Used		Priority
/var/swap/swap                          file		8388604		0		-2

However, /var/swap is a btrfs subvolume on a encrypted disk.

λ ~ » mount | grep swap
/dev/mapper/lvm on /var/swap type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=4701,subvol=/@swapfile)

Not sure how easy it is to figure out potentially more complicated setups, but it's a bit misleading as-is I reckon.

is a btrfs subvolume on a encrypted disk

How do we know it's encrypted? Any tips for https://github.com/fwupd/fwupd/blob/master/plugins/linux-swap/fu-linux-swap.c#L30 very welcome -- it's kinda dumb right now.

How do we know it's encrypted? Any tips for https://github.com/fwupd/fwupd/blob/master/plugins/linux-swap/fu-linux-swap.c#L30 very welcome -- it's kinda dumb right now.

I guess if the type is file need to go and read where it resides and check that mount if it's encrypted?

where would you suggest such an help page should reside

My gut instinct says in the hsi.xml specification page.
Well end users are currently are being referred to the Host-security-ID-runtime-issues wiki page here on github if they encounter any host specific issues hence my question.

Then specification needs to reside online someplace or be shipped with the OS which explains to end users what is being checked for, why it's being checked and what it means ( locked, unlocked, enabled/disabled etc ) and what they can do to remedy the negative output from the report like contact their hw manufacturer ( lenovo, dell etc ), file bug with their distro for unsecure defaults ( Arch,Debian,Fedora, OpenSuse etc. ) and or follow instruction in which they themselves can remedy the issue( if they can ) information which my gut feeling says does not belong in a specification.

For example: end users might expect that HSI-1 CSME checks are checking if the host system is affected by CVE-2019-0090 and CVE-2020-0566 and if those issues have been fixed on the host system but those are not listen as part of the CVE's in the specification ( which might indicate if the spec should be extended to include those and additional checks be added if needed. )

1. https://www.intel.com/content/dam/www/public/us/en/security-advisory/documents/cve-2019-0090-whitepaper.pdf
2. https://i.blackhat.com/USA-19/Wednesday/us-19-Hasarfaty-Behind-The-Scenes-Of-Intel-Security-And-Manageability-Engine.pdf
3. https://nvd.nist.gov/vuln/detail/CVE-2019-0090
4. https://nvd.nist.gov/vuln/detail/CVE-2020-0566

Then specification needs to reside online someplace or be shipped with the OS which explains to end users what is being checked for, why it's being checked and what it means ( locked, unlocked, enabled/disabled etc ) and what they can do to remedy the negative output from the report like contact their hw manufacturer ( lenovo, dell etc ), file bug with their distro for unsecure defaults ( Arch,Debian,Fedora, OpenSuse etc. ) and or follow instruction in which they themselves can remedy the issue( if they can ) information which my gut feeling says does not belong in a specification.

hsi.xml generates with the gktdoc. So the plan when it's stable is that it lands on fwupd.github.io with the rest of the procedurally generated documentation.
It's intentionally disabled right now (9d1372a#diff-46b42b4229cd7a39c564e780bb665a8bde4fdf722007e8473f167fe53ed4b995).

#2529 might be a step in the right direction.

Another potentially confusing bit:

I got the result

✘ CSME v0:12.0.47.1524:          Invalid

and was wondering what "Invalid" means. Did it fail to parse the version number or what is wrong? I digged into the code and found that FU_MEI_ISSUE_VULNERABLE gets mapped to FWUPD_SECURITY_ATTR_RESULT_NOT_VALID.

After reading what I have found about this particular issue, it looks like we are talking about specific vulnerabilities in the CSME version that can only be patched by a update from the vendor?!

So instead of "Invalid", how about introducing "Vulnerable" as a verdict for issues that belong to specific CVEs? (I assume if I wouldn't have this issue, it would say "Valid", don't know if this should be "Not Vulnerable" or "Patched").

don't know if this should be "Not Vulnerable" or "Patched

The original patch did have VULNERABLE -- by @superm1 correctly pointed out that we were using "not vulnerable" to mean "not vulnerable for this one CVE" -- if there are further weaknesses in CSME and there is another CVE then we might be showing the user CSME v0:12.0.47.1524: Not vulnerable with a big tick rather than saying something neutral.

I agree it's a bit confusing. Perhaps we want a FWUPD_SECURITY_ATTR_RESULT_VULNERABLE (and implied FWUPD_SECURITY_ATTR_RESULT_NOT_VULNERABLE) but in the CSME case we'd only use output values of VULNERABLE for we know this system is affected by that CVE and VALID for we know that system isn't affected by any of the CVEs that we knew about when this version of fwupd was released.

There is one thing left that is very unclear to me, even after reading hsi.xml as well as the resources I found online on that topic [0] [1]. So maybe there is room for improvements in the documentation.

It is about the suspend attributes:

✘ Suspend-to-idle:               Disabled
✘ Suspend-to-ram:                Enabled

Why is Suspend-to-idle more secure than Suspend-to-ram?

It is clear that Suspend-to-ram is susceptible to cold boot attacks. But as far as I understood the online resources, Suspend-to-idle is a less deep sleep state that also keeps everything in RAM while suspended. So what prevents an attacker from performing the same attack against a suspended-to-idle system?

[0] https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html
[1] https://www.linaro.org/blog/suspend-to-idle/

Fighting a coldboot attack that removes RAM can only really be mitigated by something like TME. So to that point S2I and S3 are both vulnerable. But suspend to idle is "safer" for suspend because you're not running firmware code during the resume path.

But suspend to idle is "safer" for suspend because you're not running firmware code during the resume path.

Do we have that in the spec document?

I remember talking about it, but it doesn't seem present in hsi.xml

Hint hint :)

Thank you, that explains my confusion. hsi.xml currently only mentions something about cold boot attacks which seem not to be relevant here (rather for the TME section).

I'm curious to read more about how firmware is involved during resume and how an attacker could tamper with it.

Here's a whitepaper on it: https://bromiumlabs.files.wordpress.com/2015/01/venamis_whitepaper.pdf

And this talks a little about possibilities: https://www.c7zero.info/stuff/AttackingAndDefendingBIOS-RECon2015.pdf

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.