Hello
This Secure Boot thingy in Windows 11. Is this the same that was talked about
some time ago which would only allow a WIndows OS and would not allow installing
and booting Linux ?

--
remove fred before emailing

scbs29 wrote:

> This Secure Boot thingy in Windows 11. Is this the same that was talked about
> some time ago which would only allow a WIndows OS and would not allow installing
> and booting Linux ?

yes and no.

yes, it only allows booting "trusted" O/S and Windows by default will be
on the trusted list, but you can always turn off secure boot to boot
e.g. from an untrusted O/S on disk, or on usb stick, there are also ways
to add trusted signing keys to the MOK (machine owners key database)
some distros support that.

It's never stopped me using linux (albeit temporarily) on my machines.

On 6/29/21 9:07 AM, scbs29 wrote:
> Hello
> This Secure Boot thingy in Windows 11. Is this the same that was talked about
> some time ago which would only allow a WIndows OS and would not allow installing
> and booting Linux ?

It is, although some Linux distros will now work with secure boot on
most PCs.

--
Mark Lloyd
http://notstupid.us/

"I don't want to be your other half. I believe that One and One make
TWO." -- Alanis Morrisette: "Not the Doctor".

On 6/29/21 9:21 AM, Andy Burns wrote:

> It's never stopped me using linux (albeit temporarily) on my machines.

[snip]

I did once install Linux on a certain laptop (Toshiba?) that required
disabling secure boot (and booting from MBR), but that's the only one.

--
Mark Lloyd
http://notstupid.us/

"I don't want to be your other half. I believe that One and One make
TWO." -- Alanis Morrisette: "Not the Doctor".

scbs29 wrote:
> Hello
> This Secure Boot thingy in Windows 11. Is this the same that was talked about
> some time ago which would only allow a WIndows OS and would not allow installing
> and booting Linux ?
>

https://wiki.debian.org/SecureBoot

What is UEFI Secure Boot NOT?

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the
PC market here; SB is a security measure to protect against malware during
early system boot. Microsoft act as a Certification Authority (CA) for SB,
and they will sign programs on behalf of other trusted organisations so
that their programs will also run. There are certain identification
requirements that organisations have to meet here, and code has to be
audited for safety. But these are not too difficult to achieve.

SB is also not meant to lock users out of controlling their own systems.
Users can enrol extra keys into the system, allowing them to sign programs
for their own systems. Many SB-enabled systems also allow users to remove
the platform-provided keys altogether, forcing the firmware to only trust
user-signed binaries.

Shim

shim is a simple software package that is designed to work as a first-stage
bootloader on UEFI systems.

It was developed by a group of Linux developers from various distros,
working together to make SB work using Free Software. It is a common piece
of code that is safe, well-understood and audited so that it can be trusted
and signed using platform keys. This means that Microsoft (or other potential
firmware CA providers) only have to worry about signing shim, and not all of
the other programs that distro vendors might want to support.

Shim then becomes the root of trust for all the other distro-provided
UEFI programs. It embeds a further distro-specific CA key that is itself
used for signing further programs (e.g. Linux, GRUB, fwupdate). This allows
for a clean delegation of trust - the distros are then responsible for
signing the rest of their packages. Shim itself should ideally not need
to be updated very often, reducing the workload on the central auditing
and CA teams.

For extra trust and safety, from version 15 onwards the shim binary build
is 100% reproducible - you can rebuild the Debian shim binary yourself to
verify that no unexpected changes have been embedded in this key piece of
security software.

MOK - Machine Owner Key

Generalities

A key part of the shim design is to allow users to control their own systems.
The distro CA key is built in to the shim binary itself, but there is also
an extra database of keys that can be managed by the user, the so-called
Machine Owner Key (MOK for short).

Keys can be added and removed in the MOK list by the user, entirely separate
from the distro CA key. The mokutil utility can be used to help manage the
keys here from Linux userland, but changes to the MOK keys may only be
confirmed directly from the console at boot time. This removes the risk
of userland malware potentially enrolling new keys and therefore bypassing
the entire point of SB.

*******

And a MOKUtil prompt can pop up in the middle of Linux boot

"You must answer these questions three..."

and then you don't have a browser handy, to answer the questions.

And this is why I hate this shit... and all that sailed on it.
If you MUST prompt the living shit out of people, do
it BEFORE the reboot, not DURING the reboot.

Some of your activity as a multibooter then, could involve
the "Keys page" in the BIOS. Do you particularly want to
mess up the entire machine, so you can run one stinking OS ?
The answer to that is NO.

Every time the kernel is updated in a Linux distro,
is an opportunity for MOKUtil.

Paul