mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: giorgio.nicole@arcor.de
To: "Ahmad Fatoum" <a.fatoum@pengutronix.de>,	 barebox@lists.infradead.org
Subject: AW: Re: barebox on EFI bios and secure boot
Date: Mon, 12 Aug 2024 17:26:17 +0200	[thread overview]
Message-ID: <c0c7c38e7f7d49c6ba08f8e43259e0d2@arcor.de> (raw)

Hallo Ahmad,


thank you for the answer,


>> I use barebox to boot a linux kernel on an Intel atom based PC with an EFI bios and this just works.
>> 
>> Now I wanted to configure the bios to enable the secure boot mode: this means I tried to write some
>> EFI variables (db, dbx, KEK, PK); for this I used the efitools utils (efi-updatevar for example) but it didn't
>> worked: I always get an 'Invalid argument' error.

> In this case, neither barebox or the kernel are signed, right?

yes, I can write the efi vars with the keys and certificates with the Bios gui and then enable the secure boot: then
the bios will only load properly signed bootloader or kernel images.
This already works.

>> After some unsuccessful tries I booted the linux kernel directly from the bios, without barebox and in this
>> case the efi-updatevar tool worked as expected; so I suppose that starting barebox has some kind of effect
>> on the persistent store for the efi vars.

> I am not familiar with UEFI secure boot, so I don't know if there is some lock
> down happening here or what could cause this.

Experimenting with the barebox configuration / source code (2024.8.0) I found that if I disable the PCI bus support
in the barebox configuration (CONFIG_PCI) then my Invalid argument problem disappears.

Then I tried to follow the pci bus initialization in the barebox source at: drivers/pci/pci.c and found that in the function
pci_scan_bus(), in the for loop at devfn == 105 (0x69) there appear a device with IDs 8086:5a94: as soon as I include
this device in the enumeration I have my Invalid argument problem, if I skip the device, with a hacky:

if (devfn == 105) continue;

at the beginning of the loop then the problem disappears.

It seems something very special actually and I'm not really a guru about PCI initialization...

I just hope someone with more experience on the matter can suggest a solution here; maybe the device should
really be skipped (but not with my hacky if condition).

If requested I could provide some more detail about the device...

thanks again,
giorgio





                 reply	other threads:[~2024-08-12 15:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c0c7c38e7f7d49c6ba08f8e43259e0d2@arcor.de \
    --to=giorgio.nicole@arcor.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox