<milkylainen>
How does secureboot work if U-boot provides an UEFI implementation instead of something like edk2?
<apalos>
same way as edk2
<apalos>
secureboot is described by the efi spec, so it's not something you can do differently
<milkylainen>
mkay. How does U-boot store the UEFI env? I mean. Looking from the manipulation viewpoint?
<apalos>
right now you got 2 options
<apalos>
we either have it on a file in the ESP. I think xypron is making sure that the keys can't be changed by building them in the binary
<apalos>
ofc you could change other EFI variables in that scenario
<apalos>
there's also another setup for arm devices only were you can store the keys in an RPMB or a spi device that's attached to the secure world only
<milkylainen>
I was looking through edk2 firmware support for various aarch64 boards, but it was rather thin.
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
<apalos>
yea so I re-use one part of edk2 for the variable storage
<apalos>
there's an internal application called StandAloneMM which handles the variable and storage internally
Guest2348 has joined #u-boot
<apalos>
all u-boot see's is an API to the secure world to read/get variables
<apalos>
rest is op-tee hidden magic
GNUtoo_ has joined #u-boot
<milkylainen>
hmm.
<milkylainen>
nice writeup.
<apalos>
thanks
<apalos>
there's also U-Boot and OP-TEE documentation for compiling the whole thing
<apalos>
there's a catch in op-tee but easy to fix in general
GNUtoo has quit [Ping timeout: 276 seconds]
<milkylainen>
There is so much pain in merging platform initialization. Something that should be rather straight forward becomes STUPID complex. Like either you start messing with op-tee for x86, or you start looking for other ways of symmetry from the other side.
<milkylainen>
Generally it just makes my head hurt. :)
<milkylainen>
I don't know how x86 normally secures the UEFI env?
<apalos>
it has a secure flash
<mrnuke>
milkylainen: x86 doesn't. It's some other RISC core that they don't tell you about handling all this voulnerabnility stuff
<apalos>
which can only be accessed from smm iirc
matthias_bgg has quit [Quit: Leaving]
<milkylainen>
mkay. so big unknown box.
<milkylainen>
nice.
sstiller has quit [Quit: Leaving]
<mrnuke>
Yeah, x86 is horrible in terms of bring-up
Guest2348 has quit [Quit: WeeChat 3.3]
marc has joined #u-boot
<mrnuke>
On the Intel side, you have the ME (which is ironically an ARC core licensed from Synopsis). On teh AMD side you have the PSP
marc is now known as Guest1721
Guest1721 has quit [Client Quit]
marc has joined #u-boot
marc is now known as Guest1024
sakman has quit [Quit: Leaving]
Guest1024 is now known as mfe
tnovotny has quit [Quit: Leaving]
jwillikers has quit [Remote host closed the connection]
<mwalle>
sjg1: just one node, i'm talking about the dwc3. I bind both drivers to the same node though
<mwalle>
even if i would be using two nodes, i wouldn't know how to select between them at runtime, that is not only looking at the device tree
urja has quit [Read error: Connection reset by peer]
<sjg1>
mwalle: Can you return -ENODEV from bind() ? Perhaps from probe() also
urja has joined #u-boot
behanw has joined #u-boot
<mwalle>
sjg1: what do you mean? from what I understand, there are three drivers, a wrapper (UCLASS_NOP), a host driver (UCLASS_USB) and a peripheral driver (UCLASS_USB_GADGET). the wrapper will then either call device_bind_driver_to_node() on the host driver or on the gadget driver
<mwalle>
where should i return -ENODEV?
smartin has quit [Quit: smartin]
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
v0|d has joined #u-boot
<mrnuke>
marex: Do you want the good news or the bad news about v2021.10 ?
<sjg1>
mwalle: You can add a bind() method to the two drivers and return -ENODEV in either one when you don't want it to be bound
FredO2 has quit [Read error: Connection reset by peer]
flyback has quit [Ping timeout: 245 seconds]
FredO has joined #u-boot
Trailblazer53 has joined #u-boot
vagrantc has joined #u-boot
agust has quit [Ping timeout: 252 seconds]
<Trailblazer53>
Are there any U-Boot docs that cover creating an SD card that can boot a Linux ARM? I have the Linux uImage and the U-Boot kpart, but I'm not sure how to put it all together on an SD card that will boot
<vagrantc>
it is very SoC specific
<vagrantc>
even sometimes device-specific
flyback has joined #u-boot
<mrnuke>
sjg1: I wish we had an error code -EIEIO
<Trailblazer53>
I see, how about just an example then for an ARM device that'll load U-Boot and then ARM?
<Trailblazer53>
Linux*
<Trailblazer53>
I keep seeing this design "ubi part ubi; ubi read 0x800000 kernel; bootm 0x800000", so maybe I just write the Linux uImage to a "ubi" partition and add those commands to U-Boot?
<vagrantc>
Trailblazer53: if your hardware has such a layout
<vagrantc>
Trailblazer53: it really is device-specific ... what device do you have?
<Trailblazer53>
vagrantc: It's a Lenovo IdeaPad 3 Chromebook, it's dts in mainline Linux is called mt8183-kukui-jacuzzi-fennel14.dts
<sjg1>
mrnuke: Patches welcome but you'll need to explain what it is for. Bonus points if you figure out how to add -ECOW too
<mrnuke>
sjg1: sure, Error, Io Execution not In Order
Rusty_Almighty has joined #u-boot
<mrnuke>
sjg1: Not sure about -ECOW, though I imagine we could introduce a UCLASS_COW, and shorten it to UCOW
jwillikers has quit [Remote host closed the connection]
Rusty_Almighty has quit [Quit: Leaving.]
Rusty_Almighty has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
<jimpo>
I've been having with exception handling on ARM. Mostly testing on rpi_3_32b, but same issue on odroid-xu3. I compile with CMD_EXCEPTION, then "> exception undefined" just hangs instead of showing a backtrace and returning to the prompt.