jwillikers has quit [Remote host closed the connection]
<crb>
for some reason u-boot.img isn't being built with a recent u-boot release versus an older release that did (2021.07 vs 2020.10). What controls the building of u-boot.img? I'm trying to look through the top level Makefile but I don't see it
<crb>
if it matters this is for the Xilinx zynq platform
<Forty-Bot>
have you tried `make u-boot.img`?
<crb>
yes, it's difficult to do that since this is all getting run from a ports framework on a BSD system which obviously passes down stuff I'm not aware of. I had this all working as a port with the 2020.10 version and was just trying to stay up to date
<Forty-Bot>
bisect?
<crb>
I was hoping I could get some pointers to where in the Makefile or make system u-boot.img is so that I could try to figure it out but I suppose yes I may have to bisect.
<Forty-Bot>
apparently iy is built if CONFIG_SPL_FRAMEWORK is set
<Forty-Bot>
see the INPUTS-$(...) line in Makefile
<crb>
Forty-Bot, that seemed to do it, odd that CONFIG_SPL_FRAMEWORK wasn't in my config before but now that it is the u-boot.img gets built, thanks a bunch you saved me a WHOLE bunch of time
<Forty-Bot>
:) (all I did was grep for u-boot.img in Makefile)
<crb>
Forty-Bot, sometimes that all that someone needs, I'm really bad at reading make file still
matthias_bgg has joined #u-boot
stefanro has quit [Remote host closed the connection]
stefanro has joined #u-boot
stefanro has quit [Client Quit]
stefanro has joined #u-boot
agust has joined #u-boot
monstr has joined #u-boot
smartin has joined #u-boot
frieder has joined #u-boot
fdanis_away is now known as fdanis
mckoan|away is now known as mckoan
guillaume_g has joined #u-boot
tnovotny has joined #u-boot
sszy has joined #u-boot
mrjay has joined #u-boot
<mrjay>
is u-boot spl relocation possible with current codebase on armv7?
mmu_man has joined #u-boot
cyrozap has quit [Ping timeout: 240 seconds]
cyrozap has joined #u-boot
__ad has quit [Changing host]
__ad has joined #u-boot
mrjay has quit [Quit: Client closed]
tnovotny_ has joined #u-boot
tnovotny has quit [Read error: Connection reset by peer]
mmu_man has quit [Ping timeout: 265 seconds]
jwillikers has joined #u-boot
smartin has quit [Ping timeout: 256 seconds]
mmu_man has joined #u-boot
mmu_man has quit [Remote host closed the connection]
<apalos>
sjg1: I think you've mixed up the signing and verification on the capsule update part
<apalos>
You never sign u-boot, you sing the *capsule* with an external application
<apalos>
the embeded key is needed to *authenticate* the capsule on a potential update
<apalos>
not sign anything
<sjg1>
apalos: I think I understand that. It is the same with FIT signing, right?
<apalos>
well it's an EFI certificate listt that does the public key part, but yea the idea is basically the same
<apalos>
the thing is a capsule might contain more than just u-boot
<apalos>
So you create the capsule and tehn sign it, externally
<apalos>
then once a capsule update happens, you erad the embedded U-Boot key and autheticate the capsule against that
<apalos>
now the point is, that on Sughosh original code (which was for QEMU only)
<apalos>
I think he was using the relocated FDT for reading the signature
<apalos>
whcih you can change by loading another device tree
<apalos>
in any case embedding it is not secure either, if we dont mark the .rodata pages as r/o on the page tables
<apalos>
But that's something that's on my todo list
<apalos>
and in order for this to work, you need SPL or TF-A to authenticate u-boot for you. Otherwise all bets are off
<sjg1>
OK but my concern was needing to rebuild U-Boot to add the public key
<apalos>
yea because you rebuild it regardless
<apalos>
you need to update the firmware, so step 1 is rebuild the firmweare
<apalos>
and changing the embedded key doesnt mean you change the *current* update you are aiming at
<apalos>
it will change the key for the update after that
<sjg1>
I think you are missing my point
<sjg1>
building and signing are separate steps. They may even be done on separate machines
<sjg1>
e.g. a the signing machine may be very secure and the private key is very secret
<sjg1>
so you need to be able to add the public later, as is done with FIT signing
<apalos>
but we arent *signing* anything
<apalos>
the capsule is signed, not u-boot
<sjg1>
so where is the public key?
<apalos>
the public key is in u-boot's .rodata
<apalos>
the you pack u-boot, tf-a, op-tee, whatever your firmware has and sign that
<apalos>
and he way you do that currently is with an EDK2 script
<apalos>
we do have mkeficapsule.c in u-boot as well, but that's not updated to sign anything yet
<apalos>
so in that tool, we can re-use what you propose
<sjg1>
So you put the public part of the key in when building, then hope that the private part of the same key is used for signing later on?
<apalos>
ofc
<sjg1>
Only a single key is supported?
<apalos>
you dont hope for anythign, it's one vendorpacking everything, so if he messes up his key management, there's not much you can do
<apalos>
you dont sign individual binaries, if that's what you are asking
<apalos>
you are signing the entire capsule containing everything
<apalos>
the .esl it self if the efi certificate list, which can contain more than one
<apalos>
efi signature* list
<apalos>
and the format of the .esl is definede so you can concat them
<apalos>
so cat 1.esk 2.esl > 3.esl will include both
<sjg1>
Yes I understand it is signing a group of things, FIT works the same way
<sjg1>
I am just confused about the mechanics
<apalos>
ok lett me try to explain in an example
<sjg1>
Can you point me to the docs on this? The commit message is missing the info you have given above
<apalos>
a vendor creates a apsule which contains u-boot and op-tee
<apalos>
the u-boot is compiled with the public prortion built in in .rodata
<apalos>
so once he tries to update you verify the capsule signature with the .esl in .rodata
<apalos>
the doc/develop/uefi/uefi.rst has a complete example
<apalos>
It's patch 3/3 in that series
<sjg1>
OK I am familiar with FIT signing...the bits I am missing are that
<apalos>
should be in 316ab801c0d9
<apalos>
sjg1: capsule updates are weird tbh
<sjg1>
1) only one key is supported
<apalos>
the tl;dr is that you have an FMP (which is the driver that tells how to update the firmware)
<sjg1>
2) the public key is added separately since we know the private key that the signer will use
<apalos>
sjg1: yes pretty much
<sjg1>
3) so we may as well build it into U-Boot
<apalos>
yea, but that *assumed*
<apalos>
assumes*
<apalos>
1. u-boot will be verified by SPL
<apalos>
2. You can't modify .rodata pages from the command line
<sjg1>
I still think it is a bad idea but then I think the whole thing is a bad idea :-)
<apalos>
it is a bad idea :>
<apalos>
it's the bare minimum to implement it on hardware that doesnt have a place to store the key securely
<apalos>
if you have that kind of hardware, you just retrieve the public portion of the key from that
<sjg1>
If you can protect rodata why not protect the DT too? It is not intended to be written
<apalos>
bt the whole point of the patch is that for QEMU ew used to store it on an FDT you could overwrite
<apalos>
yeae so the initial idea was to read the fdt, allocate a page, store it there and make the page r/o
<apalos>
but I didnt see any mmu code mapping pages as r/o or rx^w
<apalos>
so since we dont really need to the dtb (and it complicated how to add the public key), I completely got rid of it
<apalos>
besides the dtb is supposed to describe the hardware, not be a junkyard we dump all the stuf we dont know were to put :>
<sjg1>
That's the bit I disagree with. I am seeing a trend to adding things in the image and am pushing back against it
<sjg1>
The link scripts are complicated enough. This is a job for binman
<apalos>
yea I tried to avoid doing that during linking, hence the asm .incbin magic
<apalos>
s/during linking/with the linker scripts
<sjg1>
It is also an illusion to think that you are secure, if the DT can be modified. It controls a lot of things
<apalos>
yep, which is something I am actually working on :>
<apalos>
so the idea I had is pretty simple. Right now the kernel dtb cant boot u-boot and vice versa
<sjg1>
Then perhaps your series should wait until you can protect the DT
<apalos>
so instead of waiting for things to happen, we can include 2 dtbs in u-boot
<apalos>
the key is not in the dtb now, Heinrich merged those abnd I seriously think the dtb is the wrong place to put a signature
<apalos>
but wrt the dtb you are right, I am preparing patches that will build u-boot with 2 dtbs
<apalos>
one for u-boot and one for the OS, then the dtb gets 'naturally' verified, assuming gain you are veryfying u-boot
<apalos>
the long term plan as far i know is the dtb evolution project, were you'll be able to sign it
<sjg1>
I completely disagree about the dtb being the wrong place, 100%
<sjg1>
DT is U-Boot's configuration mechanism and we should not be shoving things in the image
<Slimey>
can some kind soul tell me the last version t1023wlan was supported in?
<apalos>
sjg1: how is that different? The dtb gets included into u-boot anyway
<apalos>
and it's u-boot that provides the capsule updateto begin with, so it's responsible for doing the evrification
<sjg1>
DT is U-Boot's configuration mechanism and we should not be shoving things in the image
<sjg1>
DT is a dict format, it can be inspected, etc. I just don't know what else to say
<sjg1>
Just fix the DT protection if that is your real problem
<apalos>
I can always ask Rob wrt to dt, but I am pretty sure he wont agree on having a key there
<sjg1>
What does it have to do with Rob? This is U-Boot, right?
<apalos>
device tree is a spec, which we are actually trying to consolidate, so u-boot wont deviate for teh kernel hat muchg
<apalos>
putting random stuff in there, is putting the horse behind the cart
<sjg1>
It is not random stuff, you need to get over that. This is U-Boot and you need to follow the U-Boot conventions
<sjg1>
I am been over this many times over the years. U-Boot does not have a user space to provide policy and config
<apalos>
was there more code that is putting keys into a DTB?
<sjg1>
DT is the config mechanism
<apalos>
because I thought that was part of Sughosh patches, that werent even used and they ewre only working for QEMU
<sjg1>
mkimage adds a public key to a DT and a private key to a FIT
<sjg1>
nothing to do with QEMU or Sughosh or EFI. That functionality has been there for about 6 years
<apalos>
so if you change the fdtaddr you basically change the key you read?
frieder has quit [Remote host closed the connection]
torez has joined #u-boot
<sjg1>
apalos: If you use 'fdt addr -c <addr>' you change the address of the DT and U-Boot likely stops working in random ways. The key is the least of the problems
tnovotny_ has quit [Quit: Leaving]
<Tartarus>
That at least kinda matches the kernel, modifying the running DT is limited, at the high level.
<apalos>
sjg1: what about the CONFIG_OF_SEPERATE case
<apalos>
?
<apalos>
Tartarus: Ideally we should carry whatever dtb is commited on the kernel, I hope we all agree on that :>
<apalos>
s/the kernel/whatever place the 'official' device trees are/, rather than keeping local outdated copies
<apalos>
Tartarus: as I tried to explain, the easiest way we can solve this right now, is build u-boot with 2 discrete DTBs,
<apalos>
and wait for the dtb to evolve and provide the means we need to auhenticate it
monstr has quit [Remote host closed the connection]
<Tartarus>
apalos: There's a few problems, yes.
<apalos>
havinf 2 dtb's built in should't bee too much of a problem, and keep it off by default.
<Tartarus>
One problem is that yes, dts in U-Boot need to get re-synced with the official source more often, esp with EFI_STUB and the kernel consuming the device tree we're using
<Tartarus>
And not loading in another one.
<apalos>
But explain in the docs that a secure platform start by trusting the hardware description
<apalos>
yea but the sync is quite painfull, that's why I considered embedding 2 dtb's as a start
<Tartarus>
The dts sync shouldn't be painful at all.
<apalos>
half of the TI platforms i tried didnt work
<apalos>
the ST boards are up to date as far as I know
<Tartarus>
I do keep asking the TI folks to re-sync
<apalos>
yea they dont, because either the kernel or u-boot doesnt boot :>
<Tartarus>
I wouldn't be surprised if there's once again an upstream dts broke things
<apalos>
me neither
<Tartarus>
Which platforms did you try?
<apalos>
am572x
<apalos>
that one couldnt scan the mmc using the built-in dtb
<apalos>
and using the kernel dts, didnt boot u-boot at all
<apalos>
and that's were I gave up
<Tartarus>
A beagleboard x15 then?
<apalos>
yea
<Tartarus>
OK, I'll take a peek too then thanks
fdanis is now known as fdanis_away
<wyre>
:q
<wyre>
ups 😆
<wyre>
this isn't vim
mckoan is now known as mckoan|away
<sjg1>
apalos: Should we add this to the agenda for next contributor call?
<sjg1>
apalos: CONFIG_OF_SEPARATE is the only real case we need to consider and is what the current signing mechanism uses
<apalos>
sjg1: it depends on what you want to solve
<apalos>
sjg1: since there's a config option that completely breaks the security aspect, we either forbid it
<apalos>
or, on boot up, we copy he key on a page, switch the page to r/o and read it only from there
<apalos>
but again, anyone can load an app and change the page tables
<apalos>
so if you really want some sense of security the command line should be completely disasbled
<apalos>
we can certianly discuss it, but changing page tables etc, needs a lot of work, there's currently limited code into u-boot
<apalos>
and as I said, even on what I did on EFI, the pages are just mapped as rxw,
<apalos>
So really anyone with console access can do whatever he likes
sszy has quit [Ping timeout: 246 seconds]
vagrantc has joined #u-boot
vagrantc has quit [Client Quit]
<milkylainen_>
how do I disable serial port IO for x86?
<milkylainen_>
My x86 u-boot hangs whenever polling keyboard IO.
vagrantc has joined #u-boot
<cyrozap>
milkylainen_: I think there's a setting to change the PS/2 device timeout. It's been a while, so I don't remember exactly where it is, but you should be able to set it to a shorter period or even to time out immediately.
<cyrozap>
milkylainen_: I just checked, and it's CONFIG_SEABIOS_PS2_TIMEOUT. And if you don't need PS2 keyboard support at all, you can disable CONFIG_DRIVERS_PS2_KEYBOARD.
vagrantc has quit [Ping timeout: 252 seconds]
<milkylainen_>
cyrozap: ah. tnx a lot.
<cyrozap>
milkylainen_: But I forget if CONFIG_DRIVERS_PS2_KEYBOARD is needed for Linux to be able to use PS/2 keyboards, so only disable that if setting the timeout doesn't work.
<cyrozap>
And np!
<milkylainen_>
hrrm. I can't find any of the symbols? are we talking about the same version?
<milkylainen_>
2021.07 here.
<milkylainen_>
cyrozap: -^
<cyrozap>
milkylainen_: I'm sorry, I'm an idiot. I thought this channel was #coreboot...
<cyrozap>
And I misread where you said "u-boot" as coreboot.
<cyrozap>
I guess I just had it in mind since I had some issues with coreboot not detecting a PS/2 keyboard in the past :P
<milkylainen_>
cyrozap: heh. shit happens. no worries. :D
vagrantc has joined #u-boot
vagrantc has quit [Ping timeout: 268 seconds]
vagrantc has joined #u-boot
vagrantc has quit [Ping timeout: 255 seconds]
vagrantc has joined #u-boot
<wyre>
hi guys, do you think could I flash the nand from a tftp? or just boot an image from it?
vagrantc has quit [Ping timeout: 255 seconds]
vagrantc has joined #u-boot
<wyre>
(I mean using the u-boot cli)
<cambrian_invader>
wyre: yes
<wyre>
cambrian_invader, could you give me more details? I mean, some kind of example/tutorial?
<wyre>
apparently I have to manage partitions with mtdpart
<cambrian_invader>
I mean, you don't *have* to but it certainly is nicer
<wyre>
or I don't know if this is defined in the dtb of the built image
<wyre>
yes, I do like the idea
<wyre>
much better than use a sdcard or usb device
<cambrian_invader>
I think you can just set the mtdparts variable
<wyre>
it's apparently already set in the default environment 🤔
<cambrian_invader>
great
<cambrian_invader>
so you should be able to do `mtd list` and see the partitions
<wyre>
hmmm, I've not right now available the system but i'll confirm you tomorrow 😉
vagrantc has quit [Quit: leaving]
<milkylainen_>
what does "flash the nand from a tftp" mean?
mmu_man has quit [Read error: Connection reset by peer]
<milkylainen_>
You can flash a raw nand using normal mtd tools. Data for the flash can be uploaded to u-boot via tftp, yes.
<marex>
if ubi is in use, use ubiformat from linux to retain eraseblock counters
<marex>
else you could try nand write.trimffs, but that has downsides
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
jwillikers has quit [Remote host closed the connection]
mmu_man has joined #u-boot
agust has quit [Quit: Leaving.]
mmu_man has quit [Read error: Connection reset by peer]