Groups | Search | Server Info | Login | Register


Groups > alt.os.linux.mint > #47109

Re: Secure boot

From Axel <none@not.here>
Newsgroups alt.os.linux.mint
Subject Re: Secure boot
Date 2026-03-24 06:10 +1100
Message-ID <n2dhgmFts8qU1@mid.individual.net> (permalink)
References <n288asF4krmU1@mid.individual.net> <10po0oh$329mt$1@dont-email.me>

Show all headers | View raw


Paul wrote:
> On Sat, 3/21/2026 3:02 PM, Axel wrote:
>> Should I have it on or off? at present I have it off.
>>
> See "Secure Boot", about 30% down the page.
>
>     https://en.wikipedia.org/wiki/UEFI
>
> Examples of security features.
>
>     Secure Boot     A secure enclave CPU, "measures" the boot process and checks
>                     the signing of the UEFI Boot Files. It "attests" that the
>                     boot files have not been modified. The BIOS has a certificate
>                     chain, and items can be "revoked" when stored in there so they
>                     are no longer trusted as certificates.
>
> Not Secure Boot    Whatever you boot with, is implicitly trusted and is not measured.
>                     A Boot Kit which has taken over the boot materials, can then be
>                     a persistent threat, living on the machine.
>
>    Automatic        When you don't have to enter your password at Linux startup,
> authentication     this gives the visitor to your household, access to your home
>                     directory and your email Inbox. It does not give elevation
>                     as a "sudo" command still requires typing in a password.
>
>     Entry           Having to enter a password right after the OS boots, ensures
> Authentication     that getting access to your home directory, requires knowing a secret.
>                     Using "sudo" still requires typing the password too.
>
> *******
>
> As for device implementations, there can be a 14 pin or a 20 pin header
> for manual insertion of a device. The device can sit on SPI or LPC
> (in other words, more than one bus type is supported).
>
> The BIOS also can have a firmware implementation of TPM. The processor
> must have a secure enclave, as part of that firmware. A TPM physical chip has
> a secure enclave, which is how older processors could have a root of trust.
> Newer processors have a core which does nothing but function as a secure
> enclave. On Intel this might be "TXT". On AMD, there are the regular x86
> cores, but there is one ARM core inside the AMD processor, which is not
> intended for, say, running a smartphone in there, that core is used
> to make a TPM via BIOS firmware. One laptop with a particular AMD
> processor, has a Pluton prototype inside it, which sank like a rock
> from a public relations point of view. The processor likely has at
> least one ARM core plus the Pluton (in case the Pluton sank like a rock).
>
> In Windows, it's easy to check your TPM status. There are two lines in
> the interface.
>
>      Status
>
>      Attestation  Ready  <=== both some sort of TPM is present, plus code that
>                               interfaces with the results
>
>      Storage      Ready  <=== presumably, holds a BitLocker key or similar
>
> My Dell Optiplex 780 claims to have a TPM, but Attestation is not ready
> and the machine does not Secure Boot. It might be a TPM 1.4 module, soldered
> to the motherboard. The storage is likely Ready (as storing a key is pretty easy).
>
> A motherboard that supported TPM 1.4, is unlikely to receive a BIOS update
> to make it TPM 2.0 ready, nor is it likely the manufacturer will make
> a TPM 2.0 module for it. If they do make a TPM module, they would then
> be on the hook for issuing a new motherboard BIOS file (which is not
> going to happen). This is how perfectly good motherboards get frozen out
> of this nonsense.
>
> The topic is migraine-inducing, just like the maintenance web page
> for Intel Management Engine and all its versions. You really as a human,
> could not read to the end of that filth. I had to stop. The TPM topic
> is just as bad, as virtually every discussion thread is incomplete,
> the people who know what they're doing, are not writing 100 page
> missives to help anyone. If you knew everything about it, you
> could likely exploit it and beat the crap out of it. That's why we
> have Boot Kits out there. Some keys, via db/dbx may already
> have been revoked. And Microsoft is in the process of installing
> PCA 2023 and eventually, revoking PCA 2011 (which means some older
> Linux DVDs, if started in Secure Boot mode on a 2026 laptop,
> will not boot -- DVDs which depend on PCA 2011 will eventually
> expire for 2026 laptops). Since PCA 2011 is expiring in July,
> officially its days are numbered anyway, but there is a claim
> that some boot processes do not trust nor check the time clock
> (as a user could just dial the clock back to "make" PCA 2011 work).
>
> I informed people a couple of years ago, that they should
> enjoy the opportunity to buy UEFI/CSM motherboards and
> computers, as 2026 was coming, and the plan was to have
> only UEFI and no CSM any more. A machine with both, can boot
> Knoppix 5.3, if you use "noacpi" on the boot line. A 2026 laptop
> is unlikely to boot Knoppix 5.3 (as a test of the flexibility
> of boot). I don't know if a 2026 laptop has a Secure Boot ON/OFF
> or not. It might be Secure Boot only, raising the possibility
> of bricking it.

thanks for that. I'll just leave it off. computing was much simpler 
before all this crap.

>
>     Paul


-- 
Linux Mint 22.3

Back to alt.os.linux.mint | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Secure boot Axel <none@not.here> - 2026-03-22 06:02 +1100
  Re: Secure boot "Alan K." <alan@invalid.com> - 2026-03-21 15:35 -0400
    Re: Secure boot Axel <none@not.here> - 2026-03-22 17:23 +1100
    Re: Secure boot Axel <none@not.here> - 2026-03-24 06:48 +1100
      Re: Secure boot rbowman <bowman@montana.com> - 2026-03-24 01:14 +0000
  Re: Secure boot rbowman <bowman@montana.com> - 2026-03-22 04:05 +0000
    Re: Secure boot Axel <none@not.here> - 2026-03-22 17:23 +1100
  Re: Secure boot Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-22 05:18 +0000
    Re: Secure boot Axel <none@not.here> - 2026-03-22 17:25 +1100
  Re: Secure boot Paul <nospam@needed.invalid> - 2026-03-22 02:03 -0400
    Re: Secure boot Axel <none@not.here> - 2026-03-24 06:10 +1100
      Re: Secure boot Paul <nospam@needed.invalid> - 2026-03-23 17:02 -0400
        Re: Secure boot Axel <none@not.here> - 2026-03-25 10:37 +1100

csiph-web