Menu ▾ ▴

#409 Secure boot issue between clonezilla versions

testing_clonezilla
open
nobody
secure boot (1)
5
2023-10-30
2023-09-20
Valerio Vanni
No

I found that latest clonezilla versions make some change in secure boot area that prevent older versions from booting.
I haven't tried all old version, my "official" stable now is 2.8.1-12 (for performance reasons explained here: https://sourceforge.net/p/clonezilla/bugs/395/).

1) Brand new machine: secure boot enabled in bios settings, Windows "msinfo32" shows secure boot active, I can use Clonezilla live 2.8.1-12 as many times as I want).
2) Boot with an older stable (I have here 3.0.3-22 on a USB key): Windows still show secure boot active, Clonezilla live at the earliest stage (just after boot device selection in bios menu) shows for a second 7-8 lines of "error: prohibited by boot secure policy" but then goes on to its start screen and can boot. Even if I restore an image, everything remains ok.
3) I still can use 2.8.1.12
4) Boot with current stable 3.1.0-22: same error "prohibited by...", then it starts. And even without restoring an image, something happens in Secure boot area (see next step).
5) I'm not able to use 2.8.1-12 anymore: at start it says "verification failed 0x1A security violation". Windows "msinfo32" still shows secure boot active.
6) I flash bios on motherboard, same version as before. And I come back to step one, where 2.8.1-12 can start.

This sequence has been tested more times.

Discussion

  • Steven Shiau

    Steven Shiau - 2023-09-22

    How about the testing Clonezilla live? i.e., >= 3.1.1-18 or 20230903-mantic?
    https://clonezilla.org/downloads.php

    Steven

     

  • Valerio Vanni

    Valerio Vanni - 2023-09-22

    Just tried, this was easy. I was sure I had already tested it, but now I'm more sure.

    -Secure boot active.
    -Start 2.8.1.12: OK
    -Shutdown
    -Start 3.1.1-18: OK (error shown but it goes on). I only get to the "start clonezilla | enter shell" page. I choose "enter shell".
    -Shutdown
    -Start 2.8.1.12: failed

    I'll try mantic.

     

    Last edit: Valerio Vanni 2023-09-22

  • Valerio Vanni

    Valerio Vanni - 2023-09-22

    Tried mantic, same as 3.1.1-18.
    I add a detail on the error shown (identical in both cases).
    It appears very quickly so I took a video.

    The two line say:
    error: prohibited by boot secure policy
    error: no video mode

     

  • Valerio Vanni

    Valerio Vanni - 2023-09-23

    I discovered two things:

    1) The latest version that doesn't trigger the issue is 3.1.0-11, the first that triggers it is 3.1.0-15.
    2) To trigger the issue, it is not necessary to reach the page "start clonezilla | enter shell". It's enough to get to the first page with grub entries and then shutdown.

    I read in both cases "grub 2.06-8": what could be different at that, so early, stage?

     

    Last edit: Valerio Vanni 2023-09-23

  • Valerio Vanni

    Valerio Vanni - 2023-09-26

    I tried with a Debian 12 live cd, same issue.
    Even this time, there's no need to go on with install: reaching the page with Grub boot entries is enough to prevent 2.8.1-12 from booting.

    So I'll try to open a bug with Debian. Now that I've found an official "killer" version, I'd like to find an official "killed" one. It's better if I can report "Debian live version x breaks secure boot for live version x-1 or x-2".

    I ask to you: what version of Debian live should I download to have a 2.8.1-12 Debian counterpart?

    In changelog I read:

    Clonezilla live 2.8.1-12

    The underlying GNU/Linux operating system was upgraded. This release is based on the Debian Sid repository (as of 2022/Jan/03).
Language file huHU updated. Thanks to Greg.

    -- Steven Shiau <steven at="" stevenshiau="" org=""> Tue, 04 Jan 2022 21:56:00 +08*</steven>

    But I don't remember, what was sid then? 10? 11?
     

    Last edit: Valerio Vanni 2023-09-26

  • Steven Shiau

    Steven Shiau - 2023-09-29

    "I ask to you: what version of Debian live should I download to have a 2.8.1-12 Debian counterpart?" -> Well, we always use live-build from Debian to build Clonezilla live, and the repository is Debian Sid.
    Hence it's difficult to find what the counterpart of Debian testing or stable is.
    You can try to check the packages list file "live/filesystem.packages" in Clonezilla live 2.8.1-12, and compare that with some specific Debian live.

    Steven

     

  • Valerio Vanni

    Valerio Vanni - 2023-10-12

    I did further testing: new grub versions update SBAT revocation list, and old grub versions are banned.

    I check with "mokutil --list-sbat-revocations"

    In the following conditions:
    -brand new machine
    -with just reflashed bios machine
    -machine with installed Windows 10 or Windows 11 (both with latest updates)
    -machine with Fedora (both live and installed)
    -machine that has loaded Clonezilla live <= 3.1.0-11

    Clonezilla 2.8.1-12 can start
    sbat revocation list is
    sbat,1,202103218

    When a Clonezilla live > 3.1.0-11 (or a recent Debian live, I didn't dig down on older ones) is loaded (just loaded at grub page with entries), grub updates sbat revocation list that become

    sbat,1,2022052400
grub,2
     

    Last edit: Valerio Vanni 2023-10-12

  • Valerio Vanni

    Valerio Vanni - 2023-10-30

    This SBAT update does not seem a safe action. The most worrying scenario is not that old Clonezilla get blacklisted, but that a resident OS get blacklisted.

    A live environment is (usually) believed to alter as little as possible a system. In particular source machine of a clone action.

    Let's say we have a machine, with a resident Linux of some year ago. Working.
    Not safe as a newer one? Perhaps, but it's not something we are supposed to change. Perhaps it's in a protected environment, perhaps it has to host some old software etc. Not our matter.

    We have to clone it, we load Clonezilla and save an image.
    Then we reboot, and the machine doesn't boot again. "Verification failed 0x1A security violation".

    At that point, to recover, we could flash firmware again to restore previous state. But it's not an easy way (is it alway easy to find firmware?), and (in general) a delicate action. We get all BIOS parameters resetted to default, we have to restore them etc.

    Or we have to disable permanently secure boot in bios settings.

    Now I've found another option to recover:

    -in bios settings, disable secure boot
    -load new clonezilla live (tried with the version that updated the blacklist)
    -open shell, and run "mokutil --set-sbat-policy delete" (with "mokutil --set-sbat-policy previous" nothing changes"
    -reboot with same clonezilla live (it's enough to reach boot grub entries, the "mokutil --set-sbat-policy delete" is run at this stage, just as blacklist update)
    -shutdown
    -in bios settings, enable secure boot

    At this point, don't reload new Clonezilla live. Another grub load would set the bigger blacklist again.

    To check, we can load a Fedora live (as it doesn't touch SBAT) an issue a "mokutil --list-sbat-revocations" to see that list is again (in my case) sbat,1,202103218.

     
    👍
    1

Log in to post a comment.