Re: Debian live boot corrupting secure boot

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

Re: User cannot start X (device already taken)

[Jeffrey Walton]

On Thu, Sep 28, 2023 at 8:25 PM Andrew M.A. Cater  wrote:
>
> On Thu, Sep 28, 2023 at 11:22:56AM -0400, Haines Brown wrote:
> > Running Devuan Chimaera
>
> In general, most people on this list run Debian. Sadly, any advice we
> can give on Devuan is likely to be best endeavours only as many of
> us are not familiar with what Devuan may choose to do.
> [This is true for every Debian derivative].

According to , the Devuan mailing
list is at .

The DNG mailing list is probably a better place to ask.

Jeff

Re: User cannot start X (device already taken)

[Andrew M.A. Cater]

On Thu, Sep 28, 2023 at 11:22:56AM -0400, Haines Brown wrote:
> Running Devuan Chimaera
> 

In general, most people on this list run Debian. Sadly, any advice we
can give on Devuan is likely to be best endeavours only as many of
us are not familiar with what Devuan may choose to do.
[This is true for every Debian derivative].

With every good wish, as ever,

Andy Cater

> ...
> 
> Help much appreciated
> 
> -- 
> 
>  Haines Brown 
> 

Re: User cannot start X (device already taken)

[Curt]

On 2023-09-28, Haines Brown  wrote:
>
>
> This is extract from Xorfg.0.log after user fails to start X
>
> ...
> [ 49400.912] (II) UnloadModule: "libinput"
> [ 49400.912] (II) seatd_libseat try close /dev/input/event18 (36:36)
> [ 49400.912] (EE) [libseat/backend/logind.c:184] Could not stat fd 36
> [ 49400.912] (EE) seatd_libseat close failed -9
> [ 49400.912] (II) UnloadModule: "libinput"
> [ 49400.912] (II) seatd_libseat try close /dev/input/event16 (35:35)
> [ 49400.928] (II) UnloadModule: "libinput"
> [ 49400.928] (II) seatd_libseat try close /dev/input/event20 (34:34)
> [ 49400.928] (EE) [libseat/backend/logind.c:184] Could not stat fd 34
> [ 49400.928] (EE) seatd_libseat close failed -9
> ...
>
> Help much appreciated
>

This seems related:

https://dev1galaxy.org/viewtopic.php?id=6019

-- 

User cannot start X (device already taken)

[Haines Brown]

Running Devuan Chimaera

Without doing anything unusual, suddenly can no longer start X, while 
root can do it. This is what is returned to terminal:

...
(II) [libseat/backend/seatd.c: 64] Could not connect to socket
 /run/seat.sock: no such file or directory
(II) [libseat/libseat.c: 76] Backend 'seatd' failed to open seat,
 skipping
(II) [libseat/libseat.c: 73] Seat opened with backend 'logind'
(DB) [libseat/backend/logind.c: 161] DRM device opened, current
 total: 1
xf86EnableIO: failed to enable I/O Ports -03ff (Operation not
permitted
(EE) [libseat/backend/logind.c: 137] Could not take device: Device
  aleady taken
(II) Server terminated.


This is extract from Xorfg.0.log after user fails to start X

...
[ 49400.912] (II) UnloadModule: "libinput"
[ 49400.912] (II) seatd_libseat try close /dev/input/event18 (36:36)
[ 49400.912] (EE) [libseat/backend/logind.c:184] Could not stat fd 36
[ 49400.912] (EE) seatd_libseat close failed -9
[ 49400.912] (II) UnloadModule: "libinput"
[ 49400.912] (II) seatd_libseat try close /dev/input/event16 (35:35)
[ 49400.928] (II) UnloadModule: "libinput"
[ 49400.928] (II) seatd_libseat try close /dev/input/event20 (34:34)
[ 49400.928] (EE) [libseat/backend/logind.c:184] Could not stat fd 34
[ 49400.928] (EE) seatd_libseat close failed -9
...

Help much appreciated

-- 

 Haines Brown 

Re: Debian live boot corrupting secure boot

[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

Re: Debian live boot corrupting secure boot

[The Wanderer]

On 2023-09-28 at 05:16, Valerio Vanni wrote:

> On Wed, 27 Sep 2023 22:14:57 -0400 The Wanderer  
> wrote:

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

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/

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



signature.asc
Description: OpenPGP digital signature

Re: Debian live boot corrupting secure boot

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

Re: Debian live boot corrupting secure boot

[Valerio Vanni]

On Wed, 27 Sep 2023 22:14:57 -0400 The Wanderer  
wrote:



The failure at (3) sounds like what happened when old grub images
were blacklisted in the UEFI Revocation List dbx. Also see
.

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.