So there are some things here that just sound like bugs:

• The long list of security events (according to @rhughes , the security history should usually be empty or have very few items)
• The insensitive expander rows - gnome-control-center#203
• The event names in the list. I think they should sound like events, like "Encrypted RAM Disabled".

Some explanation for the other questions:

Security levels

There are three goals behind the security levels, I think:

1. Some hardware is sold as having a particular security level, and it's a way to check that it conforms to spec
2. It's a way to diagnose and fix security issues. The most accessible "fixes" are updating firmware, changing something in the BIOS, or hassling a manufacturer to provide firmware updates.
3. A way to identify manufacturing errors.

Security events

The security events are generated when tests that previously passed fail. That could be a sign that the device has been tampered with, and there are plans to show a notification if the security tests have regressed since last boot. This list of events would be where those notifications would point to.

It should also maybe be mentioned that there are outstanding improvements to the descriptions, here: gnome-control-center#1990.

The security levels are probably the most challenging aspect of the design. On the one hand, it does seem that there are systems out there whose security could be improved by changing some BIOS settings. On the other hand, I don't think we should expect most users to do that.

I'd be fine with putting the brakes on this and rethinking aspects of the design, including that one.

Security levels

1. It's a way to diagnose and fix security issues. The most accessible "fixes" are updating firmware, changing something in the BIOS, or hassling a manufacturer to provide firmware updates.

I don't remember where I mentioned this, possibly in the original MR, but if it's a way to fix security issues, then the panel needs to include information on how to do that.

I don't remember where I mentioned this, possibly in the original MR, but if it's a way to fix security issues, then the panel needs to include information on how to do that.

It does do that, but the wording isn't very good. See gnome-control-center#1990.

If you're evaluating the panel can you use the fwupd in this copr please, otherwise you're going to get a degraded experience (no actions, no translated long descriptions) https://copr.fedorainfracloud.org/coprs/rhughes/fwupd/ -- that version of fwupd will be released in the next few days and pushed into Fedora.

I'm not sure about the duplicated events, that just sounds like a bug. If someone can file it in gitlab we can have a look. Most users should have almost zero events.

This is how it looks for me (with fwupd from the copr and after restarting fwupd): https://kalev.fedorapeople.org/device-security.png

This is how it looks for me (with fwupd from the copr and after restarting fwupd): https://kalev.fedorapeople.org/device-security.png

The number and naming of those security events doesn't look good to me, indeed. I'm also a bit perplexed by the time stamps in the history.

Can you try with gnome-control-center from the main branch? This is what I see on a fresh installed Lenovo laptop, where I manually turned on IOMMU in the firmware settings and then rebooted.

I think we need to heavily filter the events and only show a select few. Can you upload your /var/lib/fwupd/pending.db somewhere where I can see what's going on? Thanks.

Can you try with gnome-control-center from the main branch? This is what I see on a fresh installed Lenovo laptop, where I manually turned on IOMMU in the firmware settings and then rebooted.

Why? There are no changes to panels/firmware-security/ in git after 43.beta release that's in Fedora and that everyone is testing.

I think we need to heavily filter the events and only show a select few. Can you upload your /var/lib/fwupd/pending.db somewhere where I can see what's going on? Thanks.

Sure, here you go, and thanks for looking at it! https://kalev.fedorapeople.org/pending.db

@kalev can you try with the wip/hughsie/hsi-events branch in gnome-control-center please? I need to fix the encrypted memory events (we changed the value in newer fwupd, so ignore those two for a few mins).

Much better :) Only encrypted memory left in the events now, https://kalev.fedorapeople.org/device-security2.png

@rhughes yes, your log is shorter, but "IOMMU Protection" is still not an event.

An event would be "IOMMU Protection enabled" or something like that.

An event would be "IOMMU Protection enabled" or something like that.

We used to have that, but IIRC Allan didn't want that.

And how is "Encrypted RAM" an event? It should be "Memory encryption disabled".

And why does it show up in Kalev's log? Is something in userspace disabling this after boot?

Kalev, can you show how the second and third level behind "Security Level 0" look?

Only encrypted memory left in the events now

@kalev - can you fetch the latest branch and try again please? I've added a workaround until we can hard depend on the latest fwupd.

Kalev, can you show how the second and third level behind "Security Level 0" look?

https://kalev.fedorapeople.org/security-level.png
https://kalev.fedorapeople.org/security-level-1.png
https://kalev.fedorapeople.org/security-level-2.png
https://kalev.fedorapeople.org/security-level-3.png

Only encrypted memory left in the events now

@kalev - can you fetch the latest branch and try again please? I've added a workaround until we can hard depend on the latest fwupd.

No change for me. I still get the encrypted ram event.

@kalev, okay, sorry about that: can you do attach fwupdmgr security --json pls?

Here you go: https://paste.centos.org/view/767abfcc

@rhughes on my system, I get a green check for "level 1" even though, when I check the details, "secure boot" is red in there - is that expected ? It seems confusing if a green on the higher level does not imply "all green" for the details

is that expected

Certainly not. Can you do fwupdmgr security --json also please, then I can emulate your system here.

With Richard's latest changes, the panel now looks much cleaner and less confusing:

I'm not using the copr version of fwupd though, which explains why the rows are insensitive and the human-friendly descriptions are missing in my screenshot.

Thanks for enduring our initial harsh criticism, Richard.

Looks like we're getting to a much better place

Here is what fwupdmgr security --json reports on my system:

@mclasen that's not the fwupd in the copr, but I can add a workaround. Can you try https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1445 and approve if that fixes the issue please.

we'll see, building control-center is a bit of a worst case, in terms of dependencies, but I'll see if I can bling out my toolbox sufficiently

We discussed this issue at today's working group meeting. If fwupd is new enough in F37 to avoid some of the issues people have seen, we think that the device security panel should be kept.

That said, the group is keen to see UI improvements in GNOME 44.

Based on last discussion, changing the milestone to F38.

Are we content with this panel now?

Are we content with this panel now?

As per https://pagure.io/fedora-workstation/issue/331#comment-814246 , I think we are for F37. I was leaving this issue open so we can revisit for F38.

Having an application that reports anything about ( device ) security ( settings --> privacy --> device security ) should provide the consumer with actionable items from the desktop environment to increase the device security ( from within that application ) and such application needs to base it's security level on the existing/available hw capabilities on the device not what exists out there to twhart threats otherwise such application will just end up always reporting devices being insecure. ( user will never reach the green state of being secure ).

The goal here is to inform users that their hardware is insecure, not to provide actionable steps to improve security for their current hardware. None of the problems flagged by the HSI levels are really actionable, except for a few items that can maybe be enabled by expert users in UEFI firmware settings.

All of my hardware is HSI level 0 and there's nothing I can do about it, but I appreciate at least knowing about the problem. Now I can consider this next time I purchase a laptop. Maybe companies that ship Linux laptops will think twice before selling a laptop that won't pass the checks.

Are we content with this panel now?

As per https://pagure.io/fedora-workstation/issue/331#comment-814246 , I think we are for F37. I was leaving this issue open so we can revisit for F38.

On second thought, I don't think that this needs to be kept around. Design changes are being worked on for F38. I'm sure that people will provide feedback when they land.