Live data from Hacker News

Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

git.zx2c4.com

11–20 of 33 posts

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#11
In every UEFI thread there’s a bunch of critics saying, “See! It doesn’t work! UEFI secure boot is pointless!”

I say that it takes this much effort to bypass it shows the opposite: that it does work, it does increase security.

Because without it, you’d be compromised already at step zero.

But like every security measure so far, it’s seemingly not perfect. Nobody is honestly surprised by that, are they?

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#12

In every UEFI thread there’s a bunch of critics saying, “See! It doesn’t work! UEFI secure boot is pointless!” I say that it takes this much effort to bypass it shows the opposite: that it does work, it does increase security. Because without it, you’d be compromised already at step zero. But like every security measure so far, it’s seemingly not perfect. Nobody is honestly surprised by that, are they?

People cheer UEFI failures because Microsoft's actions with Secure Boot and such could align with an effort to eventually completely lock out the ability to install other operating systems on bare metal on hardware you own and don't rent from Microsoft. Microsoft isn't making OEMs only install their own platform keys now, but there's nothing guaranteeing the future will be the same, especially since they can claim to support Linux on Windows through WSL.

Also the whole scheme is not better than making boot configuration read only with a hardware switch, or storing your bootloader and /boot on a read-only medium, assuming you are using full-disk encryption.

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#13

In every UEFI thread there’s a bunch of critics saying, “See! It doesn’t work! UEFI secure boot is pointless!” I say that it takes this much effort to bypass it shows the opposite: that it does work, it does increase security. Because without it, you’d be compromised already at step zero. But like every security measure so far, it’s seemingly not perfect. Nobody is honestly surprised by that, are they?

If by "compromised already at step zero" you mean "just the way computers worked for decades prior to secure boot", then yeah, I suppose.

The issue that I have heard people bring up is that it could potentially make it harder to install free and open source operating systems and thus turn consumer-grade and relatively cheap computers into less of a tool that you can use the way you want and more into an appliance.

For all the panic that ensued when stuff like secure boot and similar were first announced, and the fact that I still seem able to install my Linux distro of choice, I as somebody who has not gotten personally invested in this am not in a position to know how real such an issue is.

But I would like to know what proponents of secure boot think the technology solves and why what we had before inadequately addressed security needs. Because it seems to me that e.g. Windows will still happily get infected with viruses such that whether the boot process itself has been compromised, or just what comes immediately thereafter, does not matter too much. Or does it?

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#14

In every UEFI thread there’s a bunch of critics saying, “See! It doesn’t work! UEFI secure boot is pointless!” I say that it takes this much effort to bypass it shows the opposite: that it does work, it does increase security. Because without it, you’d be compromised already at step zero. But like every security measure so far, it’s seemingly not perfect. Nobody is honestly surprised by that, are they?

If by "compromised already at step zero" you mean "just the way computers worked for decades prior to secure boot", then yeah, I suppose. The issue that I have heard people bring up is that it could potentially make it harder to install free and open source operating systems and thus turn consumer-grade and relatively cheap computers into less of a tool that you can use the way you want and more into an appliance. Fo…

Secure boot, when working correctly, prevents the survival of rootkits. This alone is not sufficient, but it is necessary in order to allow a user of a system where a rootkit was installed to know this. Without secure boot, it is basically impossible to detect the existence of a well written rootkit, since it can control the OS tmand hide itself from any OS API, whether internal or external.

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#16

In every UEFI thread there’s a bunch of critics saying, “See! It doesn’t work! UEFI secure boot is pointless!” I say that it takes this much effort to bypass it shows the opposite: that it does work, it does increase security. Because without it, you’d be compromised already at step zero. But like every security measure so far, it’s seemingly not perfect. Nobody is honestly surprised by that, are they?

This "security" protects the kernel and the boot chain, not any user data. You will find people care very little about the security of their didn't-even-know-it-existed-kernel when it protects purely against a scenario in which all their fricking data is already considered compromised.

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#17

Does this affect Debian, or Ubuntu only?

No, and APTs refer to Advanced Persistent Threat (can be an organization, a malware, but with non-friendly or unintended intent).

And nothing to do with Debian package management that had the command and file type of “apt”.

Re: Bypass kernel lockdown/UEFI secure boot on Ubuntu 18.04 with ACPI SSDT injection

#18

Does this affect Debian, or Ubuntu only?

No, and APTs refer to Advanced Persistent Threat (can be an organization, a malware, but with non-friendly or unintended intent). And nothing to do with Debian package management that had the command and file type of “apt”.

Thanks. I'm aware it's not related to the package manager, just wanted to check.
Post reply on HN