Debian live boot corrupting secure boot

[Valerio Vanni]

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.

[Max Nikulin]

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.

[Jeffrey Walton]

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

[Valerio Vanni]

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,

[Valerio Vanni]

On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <mani...@gmail.com> 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.

Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
anymore 2.8.1-12.

>
> 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.

I didn't consider that... But it makes sense.

> 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.

As I said, the image that is not loaded anymore is older Clonezilla.
The image that alters secure boot is newer Clonezilla, and then I found
that newer Debian does the same.
I still haven't found an old version of Debian that cannot boot after
newer one (but I only tried 10 live, so far).

> 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.

Perhaps... I have no option during reflash.

BIOS has 9 month. One month ago a new version has been released: some
day ago I installed it but it behaves just like the previous.

> 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).

I'll try as soon as I have another identical machine.

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

Not only I didn't install any OS, I didn't boot any image. It's enough
to reach first page (grub entries) and the damage is done.

> On the other hand, forgot old images if you have secure boot enabled.

Or forget the new ones ;-)

[The Wanderer]

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

[Max Nikulin]

On 28/09/2023 05:35, Valerio Vanni wrote:

> On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin wrote:
>> My opinion is that just loading boot images without installing OS
>> should not modify firmware state. In this sense it may be a bug.
>
> Not only I didn't install any OS, I didn't boot any image. It's enough
> to reach first page (grub entries) and the damage is done.

Thinking more, I have realized that updating secure boot keys in
firmware may be the only way for grub to boot. You may try to search for
docs and discussions to confirm such guess.

After a vulnerability found in shim or grub (that allows to boot
malicious code having no proper signature) old keys used by Linux
distributions are revoked, new ones are generated. New images signed by
new keys are published.

Consider booting of a new image on a box having outdated set of keys
(old BIOS). The machine is unaware of new keys, so unless keys are
updated, it prohibits booting of new images as insecure ones. With up to
day keys, certificate revocation list is loaded as well making booting
of older (and thus vulnerable) images impossible. That is why just
loading of an .EFI file may prevent further booting of old images.

Perhaps loading of updated key chain might be made transient affecting
current boot only. I have no idea what are the obstacles: it is not
allowed by secure boot policy, it is not supported by firmware, it is
unreliable due to bugs in firmware, or it is just not implemented in
shim or grub.

>> On the other hand, forgot old images if you have secure boot enabled.
>
> Or forget the new ones ;-)

I have never tried it, but perhaps you may enroll your own keys and
rebuild old images to put EFI files signed by you. See "master owner keys".

With outdated keys secure boot does not protect you. Is it Windows that
prevents you from just turning secure boot off? I would not be surprised
if during some update of Windows, certificate revocation list will be
updated as well, so you would not be able to boot your old Clonezilla
any more.

Why you avoiding up to date Clonezilla? Does it have backward
compatibility issues making old backup useless?

[Valerio Vanni]

On Wed, 27 Sep 2023 22:14:57 -0400 The Wanderer <wand...@fastmail.fm>
wrote:

>>> 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?

I never found backward compatibility in Clonezilla versions, I remember
only a forward one a couple of years ago.

The reason is that the new version doesn't work as well as the old one.
It works, but performance has dropped to the floor. Disk image creation
is ok, image restore is too slow if destination is an NVME drive.

It's a serious difference, I'm not a maniac that crave for milliseconds.
In numbers: 2.8.1-12 restores a Windows main partition in 6-7 minutes,
next version 3.0.x takes 1 hour and 50 minutes. Notice: same image, from
same source to same destination.

Latest one 3.1.x are better, but they still take 70-72 minutes.

[Valerio Vanni]

On Thu, 28 Sep 2023 10:08:27 +0700 Max Nikulin wrote:

> Thinking more, I have realized that updating secure boot keys in firmware may be the only way for grub to boot. You may try to search for docs and discussions to confirm such guess.

> After a vulnerability found in shim or grub (that allows to boot malicious code having no proper signature) old keys used by Linux distributions are revoked, new ones are generated. New images signed by new keys are published.

Yes, but couldn't it add news keys without blacklisting old ones?
Remember we are talking about a live environment, not an installed one.
This is breaking something I was sure about.
I always considered loading a live environment a safe action. I've
always expected to find the machine as it was before, now I cannot
expect it anymore.

Furthermore, here we are talking about a new live that prevented another
live from booting. But it could happen that I load a live and break
loading of resident OS. Bad result.

> Perhaps loading of updated key chain might be made transient affecting current boot only. I have no idea what are the obstacles: it is not allowed by secure boot policy, it is not supported by firmware, it is unreliable due to bugs in firmware, or it is just not implemented in shim or grub.

It would be a better choice.

> Or forget the new ones ;-)
>
>
> I have never tried it, but perhaps you may enroll your own keys and rebuild old images to put EFI files signed by you. See "master owner keys".

Do you mean load new EFI files in old Clonezilla?

> With outdated keys secure boot does not protect you. Is it Windows that prevents you from just turning secure boot off? I would not be surprised if during some update of Windows, certificate revocation list will be updated as well, so you would not be able to boot your old Clonezilla any more.

Windows works with or without secure boot, but I'd like to leave it on.
So far, no Windows update did such thing. I also tried update from
Windows 10 to Windows 11, and nothing happened.

Neither latest BIOS update from Asus (released at start of this month)
prevented anything to boot. Perhaps hardware manufacturers choose not to
blacklist anything, and only new grubs blacklist old ones?

[The Wanderer]

Yow. That's a pretty serious regression.

> Latest one 3.1.x are better, but they still take 70-72 minutes.

That's better, as you say, but still a pretty serious regression.

I see that you've filed a bug report [1] about this, which appears to be
getting active(-ish) attention, so that's good; this thread is then just
about something problematic-seeming that you've encountered when trying
to work around the problem.


[1] https://sourceforge.net/p/clonezilla/bugs/395/

[Stefan Monnier]

> With outdated keys secure boot does not protect you.

Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
(and is not designed to protect you either).


Stefan

[Max Nikulin]

On 28/09/2023 16:45, Valerio Vanni wrote:
> On Thu, 28 Sep 2023 10:08:27 +0700 Max Nikulin wrote:
>
>> After a vulnerability found in shim or grub (that allows to boot
>> malicious code having no proper signature) old keys used by Linux
>> distributions are revoked, new ones are generated. New images signed
>> by new keys are published.
>
> Yes, but couldn't it add news keys without blacklisting old ones?

It is beyond my knowledge of UEFI and secure boot: specs, requirements
from Microsoft, and state of affairs with bugs in implementations. That
is why I am suggesting to check for discussions related to shim & grub
and to ask people involved into their development.

>> I have never tried it, but perhaps you may enroll your own keys and
>> rebuild old images to put EFI files signed by you. See "master owner
>> keys".
>
> Do you mean load new EFI files in old Clonezilla?

Yes, I do. My idea is to build custom image of old Clonezilla with EFI
files signed by you own keys. The downside is that you need to install
your keys to every box where you are going to boot your images.

By the way, perhaps tools for management of secure boot keys allow to
replace entries causing issues in your case without full reflash of
BIOS. I have heard that some people wipes Microsoft keys completely to
have full control what images can be booted on their machines.

>> With outdated keys secure boot does not protect you. Is it Windows
>> that prevents you from just turning secure boot off? I would not be
>> surprised if during some update of Windows, certificate revocation
>> list will be updated as well, so you would not be able to boot your
>> old Clonezilla any more.
>
> Windows works with or without secure boot, but I'd like to leave it on.
> So far, no Windows update did such thing. I also tried update from
> Windows 10 to Windows 11, and nothing happened.

Notice, it is still just a hypothesis that your issues are caused by new
keys and it has to be confirmed by comparison key lists before and after.

If latest installation, repair, etc. images from Microsoft do not cause
the issue then chances that shim+grub may behave in a similar way is higher.

If booting grub built by Fedora or some other distribution unrelated to
Debian, does not cause the issue then it may be Debian specific bug. Am
I right that Clonezilla is based on Ubuntu, so may use same patches?

I do not know what is your threat model, so I am unsure why you consider
that secure book with revoked keys still provides enough degree of
protection. My impression is that not so much efforts are required to
inspect latest CVEs and to trick some signed EFI file to force booting
of a malicious EFI file. It is a reason why I suggest to disable secure
boot.

[Steve McIntyre]

Sigh. Lose the misinformation crap, please. It's getting tedious.

--
Steve McIntyre, Cambridge, UK. st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

[to...@tuxteam.de]

On Fri, Sep 29, 2023 at 10:50:37AM +0100, Steve McIntyre wrote:
> Stefan wrote:
> >> With outdated keys secure boot does not protect you.
> >
> >Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
> >(and is not designed to protect you either).
>
> Sigh. Lose the misinformation crap, please. It's getting tedious.

He-said-she-said.

JFTR. I don't know about the exact number, but I tend to agree with
Stefan here. But since we aren't exchanging arguments but just ready
made conclusions, the discussion doesn't lead anywhere.

One thing we can agree, though, may be that secure boot gives more
control of the platform to the hardware maker (who, after all is
the one choosing the TPM and the firmware going in and around there).

Whether the hardware maker is your ally, Microsoft's ally or Google's
ally (or Netflix or who-the-devil-knows) is another long and winding
discussion. I tend to think that Microsoft is higher up that list
than you & me.

Cheers
--
t

[Max Nikulin]

On 29/09/2023 17:16, to...@tuxteam.de wrote:
> He-said-she-said.

Warning! Flammable!

Let's wait till Valerio's issue will be solved.

E.g. nobody has posted commands to get list of secure boot keys so far.

[Steve McIntyre]

valeri...@inwind.it wrote:
>On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <mani...@gmail.com> 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.
>
>Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
>anymore 2.8.1-12.
>
>>
>> 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.
>
>I didn't consider that... But it makes sense.
>
>> 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.
>
>As I said, the image that is not loaded anymore is older Clonezilla.
>The image that alters secure boot is newer Clonezilla, and then I found
>that newer Debian does the same.
>I still haven't found an old version of Debian that cannot boot after
>newer one (but I only tried 10 live, so far).

The newer images might be causing firmware key revocation updates to
be applied. This is part of the Secure Boot story - if you want to
stay secure, systems will need to be updated to stop older software
with known holes from being run.

[Curt]

On 2023-09-29, <to...@tuxteam.de> <to...@tuxteam.de> wrote:
>
>
> On Fri, Sep 29, 2023 at 10:50:37AM +0100, Steve McIntyre wrote:
>> Stefan wrote:
>> >> With outdated keys secure boot does not protect you.
>> >
>> >Just to clarify: in 99.99% of the cases, SecureBoot does not protect you
>> >(and is not designed to protect you either).

>> Sigh. Lose the misinformation crap, please. It's getting tedious.

> He-said-she-said.
>

https://wiki.debian.org/SteveMcIntyre

Steve McIntyre

Steve has been a DD since October 1996 and was Debian Project Leader from
April 2008 to April 2010.
He maintains quite a few packages, but is normally most active doing DebianCd
or DebianInstaller or UEFI work. He's also an admin for this wiki!

https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot.3F

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 enroll 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.

Get a life (or change those wikis to reflect *your* truth)!

[to...@tuxteam.de]

On Fri, Sep 29, 2023 at 04:40:18PM -0000, Curt wrote:
> On 2023-09-29, <to...@tuxteam.de> <to...@tuxteam.de> wrote:

[...]

> >> Sigh. Lose the misinformation crap, please. It's getting tedious.
>
> > He-said-she-said.
> >
>
> https://wiki.debian.org/SteveMcIntyre
>
> Steve McIntyre

[...]

C'mon, Curt. You can better. Nearly everyone around here knows who Steve
is. I sure do, and I respect him a lot, but I don't have to agree with
him every time.

> UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC
> market here;

This part is just a statement of opinion (and as such not really veryfiable),
with which I disagree strongly. The rest...

> SB is a security measure to protect [...]

is a technical description, which is veryfiable and makes sense. Microsoft
is (as are all bigger corporations) an opportunistic entity. Google, for
example is a search engine, but at the same time a device to gather data
about you and to sell targeted ads. Why should they be mutually exclusive?

> Get a life (or change those wikis to reflect *your* truth)!

I'm not willing to discuss with you on this terms. I'm done. Go have your
last word.

bye
--
tomás

[Valerio Vanni]

Il 29/09/2023 05:39, Max Nikulin ha scritto:

>> Yes, but couldn't it add news keys without blacklisting old ones?
>
> It is beyond my knowledge of UEFI and secure boot: specs, requirements
> from Microsoft, and state of affairs with bugs in implementations. That
> is why I am suggesting to check for discussions related to shim & grub
> and to ask people involved into their development.

I'll try. I don't feel confortable at the idea that a live environment
could do such a change. I think that a live should not modify the
system. Yes, *you* could do something when it's loaded, but an automatic
(and silent) modification at grub page seems very bad.

At least a warning "I'm going to blacklist something, do you want to
continue?".

It's like you call a technician to fix something in your house (wall
paintings, shower, taps etc), the technician thinks that main door is
not secure and (also without telling you) alter the door lock and you
cannot pass anymore. Or cannot use all your keys but only some.

The technician is live key.
And coming back from houses to IT, it's related because technician often
use live boots to diag and fix.

I see that Clonezilla and Partclone mantainers are working on the
matter. It's not simple, since the issue happens only on some hardware.

But let's say they'll fix in some month. I'll still be worried about
live linux environments.

>> Do you mean load new EFI files in old Clonezilla?
>
> Yes, I do. My idea is to build custom image of old Clonezilla with EFI
> files signed by you own keys. The downside is that you need  to install
> your keys to every box where you are going to boot your images.

Doesn't seem practical. I am the mantainer of that disk image: I keep it
updated, I keep it tested after updates and after modifications I get
from applications' mantainers.
Then I distribute the image to other technician to deploy new machine
(or reimage old ones).

I don't have all the machines in my hands. I install only some at the
customer by myself. Others go from reseller to other technicians and are
cloned by them with my image.
I should consider compatibility between me and them.

Consider also that these machines' life is with Windows 10. They are
booted with Clonezilla only before the first install and if the machine
has to be reimaged because OS is scrambled, disk is dead and replaced etc.

I understand the idea "if some key is blacklisted, it's good that this
blacklist is enrolled to machines".
But neither Asus (bios from start of September) nor Microsoft (Windows
11) do that blacklisting. If, say, I don't load Clonezilla at all,
neither old nor new one, there is no blacklist and the security level is
the same. Basically, I load new Clonezilla and get old one blacklisted.

Is that extra security level needed?

>> Windows works with or without secure boot, but I'd like to leave it on.
>> So far, no Windows update did such thing. I also tried update from
>> Windows 10 to Windows 11, and nothing happened.
>
> Notice, it is still just a hypothesis that your issues are caused by new
> keys and it has to be confirmed by comparison key lists before and after.

I'll try with
efibootmgr -v
when I have here another machine

I don't know if Clonezilla has this package installed, if not I'll try
to carry one or more *.debs on my USB key. It's not easy to install
thing in that environment, because it's not based on a stable version
but on Sid.

So when you read Clonezilla changelogs you don't read "Debian 10,11
etc", instead you find "based on Sid of a particular date".

It took many tries to carry partclone*.deb I had downloaded from deb-src
and then recompiled with modified source to test a flag. Many tries to
find right Debian version.

> If latest installation, repair, etc. images from Microsoft do not cause
> the issue then chances that shim+grub may behave in a similar way is
> higher.
>
> If booting grub built by Fedora or some other distribution unrelated to
> Debian, does not cause the issue then it may be Debian specific bug. Am
> I right that Clonezilla is based on Ubuntu, so may use same patches?

Clonezilla come in many flavours, the main line is based on Debian
(stable - testing) and the alternate one is based on Ubuntu (alternate
stable - alternate testign).

I'll try also with a non related distribution, as you suggest.

[Max Nikulin]

On 30/09/2023 20:53, Valerio Vanni wrote:
> Il 29/09/2023 05:39, Max Nikulin ha scritto:
>
>> That is why I am suggesting to check for discussions related to shim &
>> grub and to ask people involved into their development.
>
> I'll try. I don't feel confortable at the idea that a live environment
> could do such a change.

In general I agree with you, but some restrictions may exist.

> At least a warning "I'm going to blacklist something, do you want to
> continue?".

It is just speculation. To show a warning you need to execute some code.
However .efi file is considered unsafe due to unknown signature. I have
no idea concerning origin of code that injects newer keys. It should be
some special case for secure boot.

>> Yes, I do. My idea is to build custom image of old Clonezilla with EFI
>> files signed by you own keys. The downside is that you need  to
>> install your keys to every box where you are going to boot your images.
>
> Doesn't seem practical. I am the mantainer of that disk image: I keep it
> updated, I keep it tested after updates and after modifications I get
> from applications' mantainers.

You may ask Clonezilla developers to make an image with old version and
new grub-signed and shim-signed. I think, you even could do it yourself.
Take an old image, put EFI, grub directories and kernel files from a new
image. Perhaps adjust some config files if they include Clonezilla
version. This way allows to avoid dealing with custom secure boot keys.

> But neither Asus (bios from start of September) nor Microsoft (Windows
> 11) do that blacklisting.

Do you mean Windows install on hard drive or Windows install image?

>> Notice, it is still just a hypothesis that your issues are caused by
>> new keys and it has to be confirmed by comparison key lists before and
>> after.
>
> I'll try with
> efibootmgr -v
> when I have here another machine

This particular command lists boot entries (location of .efi file to
boot), not secure boot keys. I mentioned it because I had an issue
namely with boot entries. In your case they may be unaffected.

If firmware has the "EFI shell" option then you may try "bcfg boot dump
-v". Unsure if it is possible to redirect output to a file.

> I don't know if Clonezilla has this package installed,

Then you may try any other live image. Perhaps some of Debian live,
grml, system rescue have necessary tools installed.

> Clonezilla come in many flavours, the main line is based on Debian
> (stable - testing) and the alternate one is based on Ubuntu (alternate
> stable - alternate testign).
>
> I'll try also with a non related distribution, as you suggest.

I mean an image from Fedora, not Clonezilla based on Fedora.

[Valerio Vanni]

Il 02/10/2023 18:45, Max Nikulin ha scritto:

>> At least a warning "I'm going to blacklist something, do you want to
>> continue?".
>
> It is just speculation. To show a warning you need to execute some code.

Yes, but I would trust a code that asks before doing some potentially
disruptive change.
I don't want to consider a live environment like a virus. I'd like to
considere it the opposite, a "safe thing" that leaves thing untouched.

>>> Yes, I do. My idea is to build custom image of old Clonezilla with
>>> EFI files signed by you own keys. The downside is that you need  to
>>> install your keys to every box where you are going to boot your images.
>>
>> Doesn't seem practical. I am the mantainer of that disk image: I keep
>> it updated, I keep it tested after updates and after modifications I
>> get from applications' mantainers.
>
> You may ask Clonezilla developers to make an image with old version and
> new grub-signed and shim-signed. I think, you even could do it yourself.

For now, it seems more practical to use old Clonezilla. I don't have
such control on the deploying chain (i.e. what version other technician
use), so I have to point towards compatibility.

For security: if Asus and Microsoft (usual "house owners") are happy
with a certain blacklist, I don't feel myself culprit of "making the
machine less secure" if i *don't load* a Linux version that blacklists
older ones.

Don't forget that the only times I break secure boot is when I test news
Clonezilla versions.

Now 2.8.1-12 works. It's fast, it loads without issues on the machines
where I need it. In few words, it does its job. Perhaps it's also
forward compatible (I didn't test with an image taken from the latest,
for some version it was compatibile).

I still hope that performance issue is fixed in future releases, it's
not wise taking for sure that 2.8.1-12 will work forever, on other
machines etc. It could be that in 2 years a chipset not supported come out.

But during last week I changed my plan. Before was "start to use new
Clonezilla as soon as it is fixed".
Now it's "Good when it's fixed, but I'll use 2.8 as long as it works".

>> But neither Asus (bios from start of September) nor Microsoft (Windows
>> 11) do that blacklisting.
>
> Do you mean Windows install on hard drive or Windows install image?

Machine comes with Windows 10 pre installed, and then it's updated from
Windows update. Then I installed Windows 11 with upgrade assistant.
So far, no blacklist of old Clonezilla.

Do you mean that installing Windows 10 or 11 from scratch could behave
differently?

>>> Notice, it is still just a hypothesis that your issues are caused by
>>> new keys and it has to be confirmed by comparison key lists before
>>> and after.
>>
>> I'll try with
>> efibootmgr -v
>> when I have here another machine
>
> This particular command lists boot entries (location of .efi file to
> boot), not secure boot keys. I mentioned it because I had an issue
> namely with boot entries. In your case they may be unaffected.
>
> If firmware has the "EFI shell" option then you may try "bcfg boot dump
> -v". Unsure if it is possible to redirect output to a file.

I'll try. Is there nothing inside Linux efi tools?

>> I don't know if Clonezilla has this package installed,
>
> Then you may try any other live image. Perhaps some of Debian live,
> grml, system rescue have necessary tools installed.

No, I want to see the condition without loading newer Linux versions.
Otherwise, I'd see the condition generated by that live.

Unless I find a "live as I like it" (meaning that doesn't alter secure
boot).

>> Clonezilla come in many flavours, the main line is based on Debian
>> (stable - testing) and the alternate one is based on Ubuntu (alternate
>> stable - alternate testign).
>>
>> I'll try also with a non related distribution, as you suggest.
>
> I mean an image from Fedora, not Clonezilla based on Fedora.

Yes, it was clear.

[Jeffrey Walton]

On Thu, Sep 28, 2023 at 12:10 AM Valerio Vanni <valeri...@inwind.it> wrote:
>
> On Wed, 27 Sep 2023 09:54:31 +0700 Max Nikulin <mani...@gmail.com> 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.
>
> Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
> anymore 2.8.1-12.

I would probably bet if you booted to Windows, the OS would check the
Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
required.

So you are probably going to have to deal with this sooner rather than
later. Both OSes are going to try to update the database with
signatures of the bad grub programs. Or I would not bet against it.

Jeff

[0] https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15

[Valerio Vanni]

Il 03/10/2023 04:01, Jeffrey Walton ha scritto:

>>> 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.
>>
>> Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
>> anymore 2.8.1-12.
>
> I would probably bet if you booted to Windows, the OS would check the
> Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
> required.

No, it hasn't happen. If you read entire discussion, it hasn't happen
nieither with Windows 10 nor Windows 11.
The only action that breaks secure boot of Clonezilla 2.8.1-12 is
reaching the page of Grub entries in recent Clonezilla and Debian live.

> So you are probably going to have to deal with this sooner rather than
> later. Both OSes are going to try to update the database with
> signatures of the bad grub programs. Or I would not bet against it.
>
> Jeff
>
> [0] https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15

Yes, no one can tell... but this update has more than six months.
So far it seems that Linux has a larger revocation database.

And, even if Windows would adobt this larger database, I keep on
considering it bad in a live environment. Be it Live Windows or Live Linux.

[Max Nikulin]

On 03/10/2023 01:34, Valerio Vanni wrote:
> Il 02/10/2023 18:45, Max Nikulin ha scritto:

>>> But neither Asus (bios from start of September) nor Microsoft
>>> (Windows 11) do that blacklisting.
>>
>> Do you mean Windows install on hard drive or Windows install image?

should be "installed"---------^

>
> Machine comes with Windows 10 pre installed, and then it's updated from
> Windows update. Then I installed Windows 11 with upgrade assistant.
> So far, no blacklist of old Clonezilla.
>
> Do you mean that installing Windows 10 or 11 from scratch could behave
> differently?

I am curious if just booting a recent media published by Microsoft (not
install, just booting till first dialog) may change secure boot keys. If
I have got you right, Windows with all updates installed still allows to
boot old Clonezilla.

I just have spotted in the news
https://security-tracker.debian.org/tracker/CVE-2023-4692
"Crafted file system images can cause heap-based buffer overflow and may
allow arbitrary code execution and secure boot bypass"

and a related link

https://github.com/rhboot/shim/blob/main/SBAT.md
Secure Boot Advanced Targeting

>> If firmware has the "EFI shell" option then you may try "bcfg boot
>> dump -v". Unsure if it is possible to redirect output to a file.
>
> I'll try. Is there nothing inside Linux efi tools?

Sorry, your question is unclear for me. I was trying to suggest a way to
inspect UEFI boot variables without disturbing its state. If Linux
images may do something with secure boot keys then I see the following
alternatives:
- Firmware may have EFI shell boot option included
- Perhaps there are some tools for Windows

[Jeffrey Walton]

On Tue, Oct 3, 2023 at 11:44 AM Valerio Vanni <valeri...@inwind.it> wrote:
>
> Il 03/10/2023 04:01, Jeffrey Walton ha scritto:
>
> >>> 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.
> >>
> >> Yes. If I load a Clonezilla live newer than 3.1.0-11, then I cannot boot
> >> anymore 2.8.1-12.
> >
> > I would probably bet if you booted to Windows, the OS would check the
> > Forbidden Signature/Secure Boot DBX and (re)apply KB5012170 [0] as
> > required.
>

> No, it hasn't happened. If you read the entire discussion, it hasn't
> happened neither with Windows 10 nor Windows 11.

> The only action that breaks secure boot of Clonezilla 2.8.1-12 is
> reaching the page of Grub entries in recent Clonezilla and Debian live.
>
> > So you are probably going to have to deal with this sooner rather than
> > later. Both OSes are going to try to update the database with
> > signatures of the bad grub programs. Or I would not bet against it.
> >

> > [0] https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15
>
> Yes, no one can tell... but this update has more than six months.
> So far it seems that Linux has a larger revocation database.
>

> And, even if Windows would adopt this larger database, I keep on

> considering it bad in a live environment. Be it Live Windows or Live Linux.

Did you see new grub vulnerabilities were just announced? [1] I would
not be surprised if both Linux and Windows updated the Forbidden
Signature/Secure Boot DBX.

You're going to have to deal with it eventually. Restoring UEFI
firmware to run an old Clonezilla is not a long term solution.

[1] https://www.openwall.com/lists/oss-security/2023/10/04/5

Jeff

[Valerio Vanni]

Il 04/10/2023 17:11, Max Nikulin ha scritto:

>>>> But neither Asus (bios from start of September) nor Microsoft
>>>> (Windows 11) do that blacklisting.
>>>
>>> Do you mean Windows install on hard drive or Windows install image?
> should be "installed"---------^

Ok, "installed".

> I am curious if just booting a recent media published by Microsoft (not
> install, just booting till first dialog) may change secure boot keys. If
> I have got you right, Windows with all updates installed still allows to
> boot old Clonezilla.

I'll try. Now I don't have the machine.

>>> If firmware has the "EFI shell" option then you may try "bcfg boot
>>> dump -v". Unsure if it is possible to redirect output to a file.
>>
>> I'll try. Is there nothing inside Linux efi tools?
>
> Sorry, your question is unclear for me. I was trying to suggest a way to
> inspect UEFI boot variables without disturbing its state. If Linux
> images may do something with secure boot keys then I see the following
> alternatives:
> - Firmware may have EFI shell boot option included
> - Perhaps there are some tools for Windows

I don't know if there is an EFI shell.

For Linux, I found this (there's no version for Debian):
https://github.com/rhboot/dbxtool

But it says it was replaced by this:
https://github.com/fwupd/fwupd

I'll try.

[Max Nikulin]

On 05/10/2023 04:06, Valerio Vanni wrote:
>
> I don't know if there is an EFI shell.

I am not sure, but some motherboards may have it preinstalled. Check
files on EFI system partition. It may be available in boot menu invoked
by some F* key (not grub menu), it may be necessary to enable it in
Firmware (BIOS) settings. On a screenshot of AMI bios some related
option is present in "Exit" menu in advanced mode.

Some commands and links:

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#UEFI_Shell

> For Linux, I found this (there's no version for Debian):
> https://github.com/rhboot/dbxtool
>
> But it says it was replaced by this:
> https://github.com/fwupd/fwupd

My impression is that fwupd may install updates if they are provided by
hardware vendors.

Concerning secure boot keys, I would start from mokutil, but since I
never debugged similar issues, I am not sure.

[Valerio Vanni]

Il 04/10/2023 17:11, Max Nikulin ha scritto:

>> from Windows update. Then I installed Windows 11 with upgrade assistant.
>> So far, no blacklist of old Clonezilla.
>>
>> Do you mean that installing Windows 10 or 11 from scratch could behave
>> differently?
>
> I am curious if just booting a recent media published by Microsoft (not
> install, just booting till first dialog) may change secure boot keys. If
> I have got you right, Windows with all updates installed still allows to
> boot old Clonezilla.

Just booting had no effect. Even a Windows 11 complete install from
scratch (on empty disk) does not block old Clonezilla boot.

Tried also with "get latest updates as soon as they are available" option.

I did it to exclude something not standard in OEM installation.

>>> If firmware has the "EFI shell" option then you may try "bcfg boot
>>> dump -v". Unsure if it is possible to redirect output to a file.
>>
>> I'll try. Is there nothing inside Linux efi tools?
>
> Sorry, your question is unclear for me. I was trying to suggest a way to
> inspect UEFI boot variables without disturbing its state. If Linux
> images may do something with secure boot keys then I see the following
> alternatives:
> - Firmware may have EFI shell boot option included
> - Perhaps there are some tools for Windows

Now I have a machine again. No, there is only the entry for "EFI shell",
but no one is included in firmware.
It wants it on a usb key, and says that you have to disable secure boot
to make it work.

So it doesn't seem to be a good diagnostic platform for secure boot.

My idea is to load tools on old Clonezilla, to compare the condition
between before and after new Clonezilla boot.
I cannot use a new Linux, because I would see a just changed condition.

EDIT:
Now I've tried Fedora live: it doesn't act like Debian. After it, I can
still boot old Clonezilla. Not only at grub page: I can also load live
environment.
This is what I expect from a live.
So I can use it to dig into secure boot keys.

[Max Nikulin]

On 11/10/2023 08:46, Valerio Vanni wrote:
> Now I've tried Fedora live: it doesn't act like Debian. After it, I can
> still boot old Clonezilla. Not only at grub page: I can also load live
> environment.

If the Fedora image is fresh enough then there are some patches either
in Fedora or in Debian. Perhaps the following one

https://sources.debian.org/src/shim/15.7-1/debian/patches/block-grub-sbat3-debian.patch/

You may check changelog, closed debian bugs, messages in developer
mailing lists for the shim package (shim-signed and shim-unsigned) and
may try to discuss the issue with shim maintainers.

[Valerio Vanni]

Il 11/10/2023 04:13, Max Nikulin ha scritto:
> On 11/10/2023 08:46, Valerio Vanni wrote:
>> Now I've tried Fedora live: it doesn't act like Debian. After it,
>> I can still boot old Clonezilla. Not only at grub page: I can also
>> load live environment.
>
> If the Fedora image is fresh enough

Yes, it's version 38.
I add that I tried to make it resident (install on internal disk), and
neither this way it changes anything.

It satisfies Secure Boot requirements, but it doesn't blacklist anything.
So it doesn't seem true what whas said (don't remember by who) at the
start of this thread, that if a system supports SB blacklists older
images for sure.

It seems a choice. A bad choice for a live environment.

> then there are some patches either in Fedora or in Debian. Perhaps
> the following one
>
> https://sources.debian.org/src/shim/15.7-1/debian/patches/block-grub-sbat3-debian.patch/
>
> You may check changelog, closed debian bugs, messages in developer
> mailing lists for the shim package (shim-signed and shim-unsigned)
> and may try to discuss the issue with shim maintainers.

With Fedora Live I could see the difference, using
# mokutil --list-sbat-revocations.

When the system is in one of these states:
-new
-reflashed
-after old clonezilla (grub entries) load
-after Fedora live load or Fedora install

This list is
sbat,1,202103218

After load of grub page of a new Clonezilla (or live Debian) the list
becomes:

sbat,1,2022052400
grub,2