tgamblin has quit [Remote host closed the connection]
tgamblin has joined #u-boot
dsimic has quit [Ping timeout: 264 seconds]
memset has quit [Remote host closed the connection]
dsimic has joined #u-boot
memset has joined #u-boot
<Jones42>
Forty-Bot: thanks, that's indeed slightly less ugly than my solution :-)
<Jones42>
Ah, no, not really... mkimage does take care of quite some stuff apparently...
shoragan has quit [Ping timeout: 256 seconds]
pgreco has joined #u-boot
shoragan has joined #u-boot
memset has quit [Ping timeout: 260 seconds]
memset has joined #u-boot
<xypron>
Jones42: dumpimage is the tool to extract images from FIT files.
<stgl>
I am trying to run Bao hypervisor on top of u-boot. I load the Bao ELF into memory at then do bootelf. U-Boot displays "Starting application at 0x..", so the ELF parsing seems to be fine. However it instantly returns back to the U-Boot shell prompt, without displaying "Application terminated", which shouldn't happen when I read the source code right...
<stgl>
Any idea what could be happening here? The target is RISC-V
aurel32 has quit [Quit: leaving]
aurel32 has joined #u-boot
ikarso has joined #u-boot
<Jones42>
xypron: yes, that's what I'm using now. but If I want to re-assemble everything, I also have to adjust the incbin paths.
<xypron>
Adding sn image without a new configuration will not beof much help. So I do not see a generic solution.
calebccff has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
calebccff has joined #u-boot
<Jones42>
basically I want to add a u-boot script and to the fitimage and sign it again. for various reasons i have to do this in my yocto image deploy folder where i have both the its and the fitimage.
<Jones42>
modifying the its, i.e.: add the script as new image and add it to the configuration is no big deal.
<Jones42>
but if i want to build the new fitimage, i need to extract the kernel and dtb from the old, (change the paths in the its) and rebuild.
<cambrian_invader>
when I was dealing with this, I just created a separate script image to sign
frieder has quit [Remote host closed the connection]
<cambrian_invader>
which was more convenient anyway, since I was storing my dm-verity parameters in it
<Jones42>
cambrian_invader: that's exactly my usecase. I'd like to have my rootfs-roothash in the signed fitimage.
<Jones42>
so you simply have two fitimages then? one for kernel/dtb and one with the script?
<cambrian_invader>
yes
<cambrian_invader>
and it also fixes the dependency issue I ran into\
<cambrian_invader>
since yocto wants to stick the kernel in the root filesystem
<cambrian_invader>
but if the kernel is in a fitimage with the dm verity params which are computed from the root filesystem...
<Jones42>
haha, that's the issue I was trying to solve for the past two weeks...
* cambrian_invader
should really get around to upstreaming this stuff
<Jones42>
uh, you don't have that online somewhere by any chance? :D
<Jones42>
I now resorted to the nuclear option and, just stuff the hashes into the fitimage right in yocto's image deploy directory...
<Jones42>
I always wondered how other people do that since it shouldn't be *that* complicated.
<Sout_>
so i stuffed the verification in a initramfs image. and let that do the verification of my main image. then throw the kernel + dtb + initramfs in a fit.
<Jones42>
initramfs could ease some of the pain, but since there is the dm-early-init, that would be most elegant
<cambrian_invader>
IMO initramfs is only necessary if: you need to support multiple hardware (so you need modules) OR you want to run fsck on your rootfs (which doesn't matter if it's read-only)
enok has joined #u-boot
memset has quit [Remote host closed the connection]
<Jones42>
cambrian_invader: but since you don't tie everything to a single configuration then, you're technically vulnerable to "mix-and-match"-attacks, right?
memset has joined #u-boot
<Jones42>
anyway, please cc me should you ever get to upstreaming your solution :-)
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Jones42>
I was hoping for pengutronix, since they recently sent their image_type_verity.bbclass to the list, but that didn't really solve my issues unfortunately
warpme has joined #u-boot
warpme has quit [Client Quit]
warpme has joined #u-boot
warpme has quit [Client Quit]
flyback has quit [Quit: Leaving]
crb_ has joined #u-boot
memset has quit [Remote host closed the connection]
memset has joined #u-boot
flyback has joined #u-boot
enok has quit [Ping timeout: 272 seconds]
crb_ has quit [Quit: This computer has gone to sleep]
<macromorgan>
dumb question, but how *secure* is the random function in U-Boot?
<Tartarus>
It Depends(tm)
<Tartarus>
Some platforms have HW random and we can and then do make use of it
<macromorgan>
right, I'm thinking of software RNG
<Tartarus>
Others? Well, we try.
<macromorgan>
wondering if it's good enough for kaslr-seed
<Tartarus>
Yes, we have hooks populating kaslr-seed today
<macromorgan>
right, but with hardware RNG
<Tartarus>
Then it's always a question of threat model
<derRichard>
macromorgan: what platform are you on?
<macromorgan>
varies... today I'm on sunxi
<derRichard>
do you have optee?
<macromorgan>
tomorrow it could be rockchip or broadcom or who knows what else
<Tartarus>
And then as derRichard is leading towards, there's relying on something else to provide it, which is hopefully more robust than ours
<macromorgan>
Not usually no
<macromorgan>
I'm checking the routines U-Boot uses now... not a cryptographic expert but it looks like it gets the instantaneous value of the timer as a seed, then hits librandom
<derRichard>
Tartarus: optee has usually access to a secure element since optee needs to produce key material
alan_o has quit [Read error: Connection reset by peer]
alan_o has joined #u-boot
<broonie>
To a certain extent it depends how critical the quality of your KASLR is. Perhaps a tiny bit of entropy is better than no entropy and gives you a little defence that's worth it.
<macromorgan>
my intention is to add a software option to the kaslr-seed since it's more or less a redundant command now that we can add stuff manually
marex has quit [Server closed connection]
marex has joined #u-boot
<macromorgan>
I just want to make sure that I'm doing so with something that suitably secure (I'm reading up on wikipedia now xorshift versus other things that could be done in librandom)
memset has quit [Remote host closed the connection]
<broonie>
If you're concerned about low entropy munging in any per board IDs like serial numbers can potentially be useful.
<Tartarus>
xypron: Did you also get the email from the readthedocs project?
<Jones42>
cambrian_invader: Thanks!
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
cambrian_invader has quit [Server closed connection]
cambrian_invader has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 244 seconds]
Jones42 has quit [Ping timeout: 252 seconds]
MrCryo has quit [Remote host closed the connection]
mmu_man has joined #u-boot
memset has quit [Remote host closed the connection]
memset has joined #u-boot
ldevulder has quit [Quit: Leaving]
jfsimon1981 has quit [Remote host closed the connection]
umbramalison_alt has joined #u-boot
umbramalison has quit [Ping timeout: 246 seconds]
<macromorgan>
am I allowed to modify something in the dts/upstream folder if I've also got the same things pending in mainline Linux, or do I have to wait for mainline Linux to merge and then ask U-Boot to sync?
<macromorgan>
porting a new board and want to be "upstream" from the get-go
memset has quit [Remote host closed the connection]
memset has joined #u-boot
eballetbo has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 272 seconds]
Kwiboo has quit [Server closed connection]
Kwiboo has joined #u-boot
mmu_man has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
memset has quit [Remote host closed the connection]
memset has joined #u-boot
crb_ has joined #u-boot
umbramalison has joined #u-boot
umbramalison_alt has quit [Ping timeout: 244 seconds]
<Tartarus>
You must wait until you can use the re-sync script to cherry-pick them
<tgamblin>
Tartarus: have you heard any rumblings of ethernet not working in newer u-boot on the BeaglePlay?
<moto-timo>
e.g. 2024.07
crb_ has quit [Quit: This computer has gone to sleep]
<tgamblin>
Yocto master has v2024.07, and when I've built core-image-full-cmdline with meta-ti and meta-arm, or even just genericarm64 with poky, it doesn't seem to work
<Tartarus>
Oh, um
<Tartarus>
I thought that was resolved for v2024.07?
<Tartarus>
Does master work?
<Tartarus>
top of tree I know works, beagleplay and some network tests are in my loop, finally, and so yes, it's working
<Tartarus>
But no, I guess the ethernet fix series didn't get in v2024.07 for Reasons
<tgamblin>
Tartarus: aha, so maybe I'll just need to backport some stuff?
<Tartarus>
yeah, it should stand out in git log tho
naoki has joined #u-boot
naoki has quit [Quit: naoki]
mckoan has quit [Server closed connection]
mckoan has joined #u-boot
vagrantc has quit [Ping timeout: 252 seconds]
umbramalison_alt has joined #u-boot
umbramalison has quit [Ping timeout: 252 seconds]
alan_o has quit [Remote host closed the connection]