Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #261941 > unrolled thread

Debian live boot corrupting secure boot

Back to article view | Back to linux.debian.user

Contents

  Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-09-26 23:00 +0200
    Re: Debian live boot corrupting secure boot Max Nikulin <manikulin@gmail.com> - 2023-09-27 05:00 +0200
    Re: Debian live boot corrupting secure boot Jeffrey Walton <noloader@gmail.com> - 2023-09-27 05:30 +0200
      Re: Debian live boot corrupting secure boot Valerio Vanni <valerio.vanni@inwind.it> - 2023-09-28 00:30 +0200
        Re: Debian live boot corrupting secure boot The Wanderer <wanderer@fastmail.fm> - 2023-09-28 04:20 +0200

#261941 — Debian live boot corrupting secure boot

Motherboard is an Asus H510M-A.

I found the issue on latest versions of Clonezilla, but then I tried 
with plain Debian live and the behavior is the same.

Booting a recent Debian USB key do some modification on secure boot that 
prevents some older OS to boot.

The cycle is:

1) Machine brand new: secure boot is active, Windows 10 shows it active, 
I can boot an old Clonezilla live (2.8.1-12) as many times as I want.

2) I boot from USB drive Debian Live 12
https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso

A note: to trigger the issue, there's no need to go on and load OS. It's 
enough to see the first page (that with grub entries) and then shutdown.

3) At next boots, secure boot refuses to boot from Clonezilla live 
2.8.1-12. The error is
"verification failed 0x1A security violation"
Windows 10 can still start, and shows secure boot active. Only if I 
disable secure boot from BIOS, I can start clonezilla.

4) I reflash BIOS, same version, and go to point 1.

Tested many times.

[toc] | [next] | [standalone]

#261946

On 27/09/2023 03:28, Valerio Vanni wrote:
> 
> I found the issue on latest versions of Clonezilla, but then I tried 
                        ^^^^^^
> with plain Debian live and the behavior is the same.

Does it mean that you can not boot your *old* Clonezilla live after 
booting a latest Clonezilla? If so, it is better to discuss the issue 
with shim or grub developers.

> 1) Machine brand new: secure boot is active, Windows 10 shows it active, 
> I can boot an old Clonezilla live (2.8.1-12) as many times as I want.
                 ^^^

An old image may be signed by a key later added to certificate 
revocation lists. If so, secure boot just works as it is supposed to do.

> 2) I boot from USB drive Debian Live 12
> https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso

If it can be reproduced with a contemporary Clonezilla or e.g. a Fedora 
image then it is not a Debian issue. If it is specific to namely Debian 
(I am unsure concerning Ubuntu, Debian derivatives) then it is better to 
file a bug providing more details.

> A note: to trigger the issue, there's no need to go on and load OS. It's 
> enough to see the first page (that with grub entries) and then shutdown.

I have an old HP laptop with buggy firmware where fbx64.efi (from shim) 
tries to fix NVRAM boot entries on each boot, so it is better to avoid 
this file on this machine. It happens before grub, but I do not think it 
is relevant to your issue.

> 4) I reflash BIOS, same version, and go to point 1.

How old is your BIOS? Maybe you just restore obsolete list signing of keys.

I suggest to compare

     efibootmgr -v

output in the state when Clonezilla may be booted and when it fails. In 
addition public keys and certificate revocation list should be compared 
(unsure concerning commands).

My opinion is that just loading boot images without installing OS should 
not modify firmware state. In this sense it may be a bug.

On the other hand, forgot old images if you have secure boot enabled. A 
security vulnerability may result in requirement to sign all boot images 
with new keys while older ones are added to revocation lists that is 
updated with firmware update or by OS.

If you can confirm that Clonezilla signing key has not been revoked then 
it is a subject for a bug report.

[toc] | [prev] | [next] | [standalone]

#261947

On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni <valerio.vanni@inwind.it> wrote:
>
> Motherboard is an Asus H510M-A.
>
> I found the issue on latest versions of Clonezilla, but then I tried
> with plain Debian live and the behavior is the same.
>
> Booting a recent Debian USB key do some modification on secure boot that
> prevents some older OS to boot.
>
> The cycle is:
>
> 1) Machine brand new: secure boot is active, Windows 10 shows it active,
> I can boot an old Clonezilla live (2.8.1-12) as many times as I want.
>
> 2) I boot from USB drive Debian Live 12
> https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso
>
> A note: to trigger the issue, there's no need to go on and load OS. It's
> enough to see the first page (that with grub entries) and then shutdown.
>
> 3) At next boots, secure boot refuses to boot from Clonezilla live
> 2.8.1-12. The error is
> "verification failed 0x1A security violation"
> Windows 10 can still start, and shows secure boot active. Only if I
> disable secure boot from BIOS, I can start clonezilla.
>
> 4) I reflash BIOS, same version, and go to point 1.
>
> Tested many times.

The failure at (3) sounds like what happened when old grub images were
blacklisted in the UEFI Revocation List dbx. Also see
<https://lwn.net/Articles/827403/>.

You should probably stop doing (4).

Jeff

[toc] | [prev] | [next] | [standalone]

#261957

Il 27/09/2023 05:22, Jeffrey Walton ha scritto:
> On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni <valerio.vanni@inwind.it> wrote:
>>
>> Motherboard is an Asus H510M-A.
>>
>> I found the issue on latest versions of Clonezilla, but then I tried
>> with plain Debian live and the behavior is the same.
>>
>> Booting a recent Debian USB key do some modification on secure boot that
>> prevents some older OS to boot.
>>
>> The cycle is:
>>
>> 1) Machine brand new: secure boot is active, Windows 10 shows it active,
>> I can boot an old Clonezilla live (2.8.1-12) as many times as I want.
>>
>> 2) I boot from USB drive Debian Live 12
>> https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/debian-live-12.1.0-amd64-kde.iso
>>
>> A note: to trigger the issue, there's no need to go on and load OS. It's
>> enough to see the first page (that with grub entries) and then shutdown.
>>
>> 3) At next boots, secure boot refuses to boot from Clonezilla live
>> 2.8.1-12. The error is
>> "verification failed 0x1A security violation"
>> Windows 10 can still start, and shows secure boot active. Only if I
>> disable secure boot from BIOS, I can start clonezilla.
>>
>> 4) I reflash BIOS, same version, and go to point 1.
>>
>> Tested many times.
> 
> The failure at (3) sounds like what happened when old grub images were
> blacklisted in the UEFI Revocation List dbx. Also see
> <https://lwn.net/Articles/827403/>.
> 
> You should probably stop doing (4).

But this way I would have to disable secure boot to load old Clonezilla.
Disable secure boot, launch clonezilla, restore image, reenable secure 
boot, start OS.

It's more complicated.


On that machine,

[toc] | [prev] | [next] | [standalone]

#261959

[Multipart message — attachments visible in raw view] — view raw

On 2023-09-27 at 18:04, Valerio Vanni wrote:

> Il 27/09/2023 05:22, Jeffrey Walton ha scritto:
> 
>> On Tue, Sep 26, 2023 at 10:20 PM Valerio Vanni
>> <valerio.vanni@inwind.it> wrote:

>>> 3) At next boots, secure boot refuses to boot from Clonezilla
>>> live 2.8.1-12. The error is
>>> "verification failed 0x1A security violation"
>>> Windows 10 can still start, and shows secure boot active. Only if
>>> I disable secure boot from BIOS, I can start clonezilla.
>>>
>>> 4) I reflash BIOS, same version, and go to point 1.
>>>
>>> Tested many times.
>> 
>> The failure at (3) sounds like what happened when old grub images
>> were blacklisted in the UEFI Revocation List dbx. Also see
>> <https://lwn.net/Articles/827403/>.
>> 
>> You should probably stop doing (4).
> 
> But this way I would have to disable secure boot to load old Clonezilla.
> Disable secure boot, launch clonezilla, restore image, reenable secure 
> boot, start OS.

Well, why do you need to load old Clonezilla? Surely the new version of
the Clonezilla live boot environment should work just as well as the old
one?

The only candidate reasons I can think of are "I have data files which I
still need to use with the Clonezilla live boot environment, and the old
version includes tools which are compatible with those files, but the
new one does not", and "I have a lot of already-created boot media with
the old version of the Clonezilla live boot environment, and I don't
want to discard or re-create all of that boot media".

The former would be a valid reason, but would also seem a bit odd;
backwards-incompatible breaks like that do not AFAIK tend to come along
very often, especially not in system-imaging solutions.

The latter would be understandable, but you'd have the choice between
doing that discard-all-the-old thing, or living with the downsides of
disabling Secure Boot.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web