Ubuntu Isn't Yet Onboard With GNOME's "Device Security" Screen

[patrick1946]

I expect my system anyway not very secure but the hacky approach of Ubuntu is harming them in other areas. After using Windows 10 for a different project I use now Fedora Silverblue on my new Computer. Since then I don't fear any update. If something breaks I simply can rollback it. And my development environment is running in a 'toolbox'. So much better than to mix it with OS. No new library, compiler etc. is breaking my development environment in the wrong moment.

Yes it is different but not so much and much less hassle. Ubuntu should stop to try to monopolise Linux with stuff like snap and just cooperate on good solutions.

[hughsie]

If they have an AMD system (which accounts for an increasingly big chunk of the Linux userbase), then there is not even a score.

Not true, we have tests for new AMD systems. Old AMD machines are not supported as they don't provide the required kernel attributes provided by the PSP that fwupd requires.

This panel tries to make security look like an on or off thing, but it's not, not really, it's more like a slider or a percentage

That's literally why it's HSI 0 to 3, i.e. there's no need for an HSI:3 system for a laptop used to watch youtube.

What is "CSME manufacturing mode" and how to I change "pre-boot DMA protection"?

Install a new fwupd version (from git master, which is planned for released on Tuesday) and you get translated multi-line long descriptions. If you wait a few more weeks we'll have buttons for things like "Turn on IOMMU" so the user doesn't have to reboot and change the setting themself. We've written the code, but it needs a lot of testing.

The article also reiterates another big misunderstanding, "A default Ubuntu install only gets us "Security Level 1". The highest level is "Security Level 3"." -- this is completely wrong, it's very little to do with the OS configuration and much more to do with the platform configuration. So you can install Ubuntu on a modern XPS or ThinkPad and you'll get a high score (2 or 3) if you install it on an old machine, or a badly configured platform you'll get a low score. It's really not very OS specific at all, unless the OS is doing something super dumb like unconditionally disabling IOMMU.

[kpedersen]

So you can install Ubuntu on a modern XPS or ThinkPad and you'll get a high score (2 or 3) if you install it on an old machine

So they really want to add an Amazon (affiliate) link in the control panel so that consumers can conveniently buy a new machine when the software (fairly arbitrarily) gives them a bad score.

[hughsie]

so that consumers can conveniently buy a new machine when the software (fairly arbitrarily) gives them a bad score.

No, clearly what we need to do is wave a magic wand and make hardware with known security problems magically secure as people don't like being told that they've spent a lot lot money on something that's now horribly insecure. We've got some heavyweight security experts checking each tested security attribute, people way clever than you and me. It's certainly not arbitrary.

[Vorpal]

Not true, we have tests for new AMD systems. Old AMD machines are not supported as they don't provide the required kernel attributes provided by the PSP that fwupd requires.

False. There is no way a Ryzen 5600X from last year on a B550 motherboard can in any way be considered "old". There isn't even a newer generation released yet. Yet it has this issue. At least on Linux 5.19 running on Arch Linux. Is there some kernel config option I should check that would be relevant? The same kernel works just fine on a Intel Skylake in providing the required info by the way.

[hughsie]

False

https://github.com/fwupd/fwupd/blob/...-psp/README.md -- it was literally written by AMD.

[Vorpal]

https://github.com/fwupd/fwupd/blob/...-psp/README.md -- it was literally written by AMD.

So which modern AMD desktop CPUs are supported then? You have been rather vague on this. Also that file you are referencing says nothing about "older" and "newer", so that claim cannot be based on that file. The file you linked makes no claims about what CPUs are able to export the information. Could it be just Epyc? Or maybe just the mobile APUs? Who knows!

[Vistaus]

This is absolutely horrendous for the end user. If they have an AMD system (which accounts for an increasingly big chunk of the Linux userbase), then there is not even a score. That might lead the user to believe their AMD system is insecure and at risk, when it's just missing some Intel-only gimmicky features. I can't believe they will ship something like that.

Not sure what's wrong, but on my AMD Ryzen 5900HX system, it does give a score.

[erniv2]

If it just exposes the data from fwupdmgr it does not seem very useful to an average user:

• Several of the settings in question can only be changed from BIOS.
• Some settings may require changes to the kernel command line (turning on IOMMU on my ThinkPad T480 for example). And those are off by default for a reason: doesn't work properly on all systems. Recovery from that is easy if you know what you are doing.
• Some settings may be unavailable for a given hardware generation or on a particular system preventing higher levels at all on that hardware.
• On my desktop with a Ryzen 5600X it just refuses to give any score at all due to missing hardware support. So it is an Intel only feature currently as far as I can tell.

So if the data is to be useful to an average user this feature currently seems half baked. In fact even to an expert user and professional software developer it is not easy to parse. What is "CSME manufacturing mode" and how to I change "pre-boot DMA protection"? Even the fwupdmgr documentation is only half-done, it only explains some of these.

The interface is there to SEE the System STATUS not to SET it.

IOMMU DMAR DMARp and Secure Boot ofcourse has to be set By the UEFI it is there to provide a safe enviroment till the OS takes control.

Secure Boot blocks bootloaders/kernels without keys, DMARp prevents hardware dma while in the UEFI so no hardware can insert Data into RAM before loading a bootloader(DMARp is against physical exploits where USB keys PCIe cards can be added so the relevance for normal users is low). DMAR is the runtime DMA remapping done by the IOMMU to prevent DMA RAM access , and both require the IOMMU to be activated in the UEFI it wont work without so no you cant activate it in Software, atmost you can deactivate it.

So the kind of interface you imagine is impossible.

EDIT: And i you want to have those features to be set by the OS good luck to find the right settings for every UEFI out there, and it will require a reboot anyway so why not just reboot and setup your UEFI correct in the 1st place.

Relying on a third party tool i consider it highly dangerous so a feature like that will never be added to a prominent place like the gnome control center, and later on the gnome devs get sued for thousends of locked Systems cause someone fiddled with that control center tab.

[Vorpal]

The interface is there to SEE the System STATUS not to SET it.

IOMMU DMAR DMARp and Secure Boot ofcourse has to be set By the UEFI it is there to provide a safe enviroment till the OS takes control.

Secure Boot blocks bootloaders/kernels without keys, DMARp prevents hardware dma while in the UEFI so no hardware can insert Data into RAM before loading a bootloader(DMARp is against physical exploits where USB keys PCIe cards can be added so the relevance for normal users is low). DMAR is the runtime DMA remapping done by the IOMMU to prevent DMA RAM access , and both require the IOMMU to be activated in the UEFI it wont work without so no you cant activate it in Software, atmost you can deactivate it.

So the kind of interface you imagine is impossible.

I believe you misunderstood me. I complained not about lack of possible actions from the GUI, but the utter lack of documentation and explaination. I do not expect most of these to have a simple "fix this" button. But I do expect:

• Explanations for what they mean/do
• Information about if the user can do anything about them, and if so what (look for things in BIOS, change kernel command line, ...)
• If applicable: Any risks associated with doing those actions (e.g. "oh by if you set the option, on some broken systems your system might not boot due to broken ACPI/UEFI/whatever. This has been observed on some vendor X and vendor Y systems so far.")
• Links to more information.