• LOL they are a problŠme with secure boot tagged MS for Tux !?#

    From german usenet@3:633/10 to All on Monday, June 22, 2026 20:43:24


    https://www.zdnet.fr/actualites/les-utilisateurs-de-linux-confrontes-a-un-casse-tete-lie-au-secure-boot-de-microsoft-voici-la-solution-497303.htm

    they are caca !



    --
    Amicalement,

    german


    --- PyGate Linux v1.5.17
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Paul@3:633/10 to All on Tuesday, June 23, 2026 00:07:20
    On Mon, 6/22/2026 2:43 PM, german usenet wrote:


    https://www.zdnet.fr/actualites/les-utilisateurs-de-linux-confrontes-a-un-casse-tete-lie-au-secure-boot-de-microsoft-voici-la-solution-497303.htm

    they are caca !

    There will be side effects.

    Some of the BIOS, even if they delivered updated content,
    the UEFI BIOS code itself is defective! And this is NOT a joke.
    The fact the certificates up to now, have been working, has
    hidden the defects in the UEFI code. After this month, we may begin
    to see boots failing WITH SECURE BOOT TURNED OFF and just hard
    drives plugged in and the BIOS delivers a black screen.

    It's going to make running some of those computers, a miserable
    experience. And buying new hardware will NOT fix it. It will
    be a casino, where you buy some of the brands and you will
    receive yet another broken BIOS implementation.

    What's needed is to get rid of all the proprietary junk
    and have the industry standardize on a "Coreboot that runs everywhere".

    Or at least, to separate the BIOS into two halves. One half,
    operates the GPIO and handles the quirks of individual hardware designs.
    The other half of the BIOS would be a standardized "boot" handler,
    with all the pretty UEFI boot items and so on, and this design
    would have to be accompanied by hardware designs with enough NAND/NOR
    storage of sufficient size to handle a deluge of db/dbx crapola.
    By deploying a scheme with 32KB sized stores, this messy situation
    CANNOT last. it's untenable, even with SBAT (and SBAT doesn't even work in
    my room, it is broken on all machines).

    I do not think the current technical articles, hint enough at
    what potentially could happen. In the past, we NEVER had to worry
    about our BIOS holding the machine hostage. Now, the situation
    is unclear and cannot even reasonably be evaluated or determined
    by mere humans.

    If there is an uptick in these issues, I will not be able to help
    you, as there is no technical means of determining whether MSI,
    Asus or Gigabyte have done a good job of configuring their
    Award or AMI BIOS. There could be weird symptoms. And buying
    a motherboard replacement -- may give more weird symptoms.

    I would not be so concerned, if Secure Boot = OFF in the BIOS
    actually worked, but it does not actually mean that, it means
    Secure Boot = "Maybe OFF (and maybe not)".

    Paul



    --- PyGate Linux v1.5.17
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From german newsgroups@3:633/10 to All on Tuesday, June 23, 2026 06:49:27
    Le 23/06/2026 … 06:07, Paul a ‚critÿ:
    There will be side effects.

    Some of the BIOS, even if they delivered updated content,
    the UEFI BIOS code itself is defective! And this is NOT a joke.
    The fact the certificates up to now, have been working, has
    hidden the defects in the UEFI code. After this month, we may begin
    to see boots failing WITH SECURE BOOT TURNED OFF and just hard
    drives plugged in and the BIOS delivers a black screen.

    It's going to make running some of those computers, a miserable
    experience. And buying new hardware will NOT fix it. It will
    be a casino, where you buy some of the brands and you will
    receive yet another broken BIOS implementation.

    What's needed is to get rid of all the proprietary junk
    and have the industry standardize on a "Coreboot that runs everywhere".

    Or at least, to separate the BIOS into two halves. One half,
    operates the GPIO and handles the quirks of individual hardware designs.
    The other half of the BIOS would be a standardized "boot" handler,
    with all the pretty UEFI boot items and so on, and this design
    would have to be accompanied by hardware designs with enough NAND/NOR
    storage of sufficient size to handle a deluge of db/dbx crapola.
    By deploying a scheme with 32KB sized stores, this messy situation
    CANNOT last. it's untenable, even with SBAT (and SBAT doesn't even work in
    my room, it is broken on all machines).

    I do not think the current technical articles, hint enough at
    what potentially could happen. In the past, we NEVER had to worry
    about our BIOS holding the machine hostage. Now, the situation
    is unclear and cannot even reasonably be evaluated or determined
    by mere humans.

    If there is an uptick in these issues, I will not be able to help
    you, as there is no technical means of determining whether MSI,
    Asus or Gigabyte have done a good job of configuring their
    Award or AMI BIOS. There could be weird symptoms. And buying
    a motherboard replacement -- may give more weird symptoms.

    I would not be so concerned, if Secure Boot = OFF in the BIOS
    actually worked, but it does not actually mean that, it means
    Secure Boot = "Maybe OFF (and maybe not)".

    Paul


    the human is saying i use tux and a w11 25h without secureboot
    and without TPM 2.0 all are off.

    y‚ with linux the boot sequence is fun ! is not coreboot but grub
    so when we read the partitions table so inside we have the Grub stage1
    and after you know...

    so, who build this ? intel with Microsoft ! we have this situation
    first with w8.

    to day i say is cool if all office in the world down ! in france
    first they are very bad dogs in france, muslim dog, big dogs, russian
    gnl dogs ! may be a day we will have a law to stop them. why not a
    crash !

    --
    Amicalement,

    Frenchy Friendly, & French touch !

    german

    --- PyGate Linux v1.5.17
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Jack Strangio@3:633/10 to All on Thursday, June 25, 2026 00:55:01
    Paul <nospam@needed.invalid> writes:
    On Mon, 6/22/2026 2:43 PM, german usenet wrote:

    Or at least, to separate the BIOS into two halves. One half,
    operates the GPIO and handles the quirks of individual hardware designs.
    The other half of the BIOS would be a standardized "boot" handler,
    with all the pretty UEFI boot items and so on

    Paul


    <grin>

    We've used this harware/software layout before. Around 1980: CP/M !

    "Plus ‡a change, plus c'est la mˆme chose."

    Jack
    --
    All plants are edible.
    Some only once.

    --- PyGate Linux v1.5.18
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)
  • From Heinz Schmitz@3:633/10 to All on Thursday, June 25, 2026 11:32:08
    Jack Strangio wrote:

    Paul <nospam@needed.invalid> writes:
    On Mon, 6/22/2026 2:43 PM, german usenet wrote:

    Or at least, to separate the BIOS into two halves. One half,
    operates the GPIO and handles the quirks of individual hardware
    designs.
    The other half of the BIOS would be a standardized "boot" handler,
    with all the pretty UEFI boot items and so on

    <grin>

    We've used this harware/software layout before. Around 1980: CP/M !

    "Plus ‡a change, plus c'est la mˆme chose."

    The question is what happens before the BIOS starts and wether we
    have tools to look at from where it does. Who will write a book basing
    on the assumption that all our PCs already are inhabitated by such a
    silent observer?

    Regards,
    H.



    --- PyGate Linux v1.5.18
    * Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)