sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
hanetzer has quit [Ping timeout: 272 seconds]
hanetzer has joined #u-boot
hanetzer has quit [Ping timeout: 260 seconds]
hanetzer has joined #u-boot
<hays>
dangit i compiled u-boot with ARM TRNG support, but I guess this A53 doesn't have it?
naoki has quit [Remote host closed the connection]
naoki has joined #u-boot
<hays>
dang.. Any creative ways to get KASLR seeded without hardware support?
<mranostaj>
i'm sure there are same creative ways.. but probably none practical
<mranostaj>
or that secure rather
<mranostaj>
so for this patch well revert (yes a decade old) the return code for mmc_send_if_cond() call isn't checked even though it is assigned to err... https://github.com/u-boot/u-boot/commit/afd5932b2c27
<mranostaj>
is that just a oversight for a decade, and accidently introduced with this revert? or is it to quiet some compiler warning about an unused return code?
<Forty-Bot>
looks like a decade-old oversight
<mranostaj>
was thinking as much.. guess i can pop a patch up
naoki has quit [Quit: naoki]
mncheck has joined #u-boot
mckoan|away is now known as mckoan
matthias_bgg has joined #u-boot
naoki has joined #u-boot
camus has quit [Ping timeout: 272 seconds]
camus has joined #u-boot
sszy has joined #u-boot
<marex>
hays: iirc zynqmp has no RNG (which is A53)
chron0 has quit [Ping timeout: 248 seconds]
chron0 has joined #u-boot
<marex>
so it could be a soc feature
<marex>
hays: which soc is that ?
<apalos>
marex: I don't remember if those have an RNG but fwiw TF-A and OP-TEE can provide you with one now if you need it
<marex>
apalos: oh wow, so they magically conjure randomness from nowhere ?
underpantsgnome[ has quit [Quit: Bridge terminating on SIGTERM]
par[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
samueldr has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
Domon has quit [Quit: Bridge terminating on SIGTERM]
ric342[m] has quit [Quit: Bridge terminating on SIGTERM]
jkorsnes[m] has quit [Quit: Bridge terminating on SIGTERM]
hthiery has quit [Quit: Bridge terminating on SIGTERM]
kallisti5[m] has quit [Quit: Bridge terminating on SIGTERM]
mripard has quit [Quit: Bridge terminating on SIGTERM]
lespocky[m] has quit [Quit: Bridge terminating on SIGTERM]
Julia[m]1 has quit [Quit: Bridge terminating on SIGTERM]
elvishjerricco has quit [Quit: Bridge terminating on SIGTERM]
Dhruvag2000[m] has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
vitali64[m] has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
kmaincent[m] has quit [Quit: Bridge terminating on SIGTERM]
<apalos>
marex: I think they both implement a DRBG as defined in NIST standards
<apalos>
but I've benver checked the details
<marex>
apalos: but if it is pseudoRNG, then it is basically not useful
vitali64[m] has joined #u-boot
apritzel has joined #u-boot
<hays>
marex: the Armada 3720 or 3700 series
samueldr has joined #u-boot
<hays>
just trying to gat KASLR working
mripard has joined #u-boot
Tartarus has joined #u-boot
lespocky[m] has joined #u-boot
jevinskie[m] has joined #u-boot
LinuxHackerman has joined #u-boot
par[m] has joined #u-boot
elvishjerricco has joined #u-boot
hthiery has joined #u-boot
mvaittin has joined #u-boot
jkorsnes[m] has joined #u-boot
underpantsgnome[ has joined #u-boot
Domon has joined #u-boot
ric342[m] has joined #u-boot
kallisti5[m] has joined #u-boot
Dhruvag2000[m] has joined #u-boot
<hays>
and yeah a PRNG needs a seed so its chicken/egg
Julia[m] has joined #u-boot
kmaincent[m] has joined #u-boot
mmu_man has joined #u-boot
<apalos>
hays: KASLR with or without EFI
<hays>
apalos: this does not have EFI
<hays>
that's not something i can add, is it?
<j`ey>
hays: u-boot has an EFI implementation
<hays>
hmm does this mean im using grub or could i just boot the kernel directly
<apalos>
you can boot the kernel directly
<apalos>
the problem without EFI is that you only randomize the virtual placement of the kernel
<apalos>
if you boot with EFI you also randomize it's initial physical placement
<apalos>
efidebug boot add -b 1 my_OS usb 0:1 efi/boot/bootarm.efi -I usb 0:1 ledge-initramfs.rootfs.cpio.gz -s 'console=ttySTM0,115200 console=tty0 root=UUID=6091b3a4-ce08-3020-93a6-f755a22ef03b rootwait panic=60'
<apalos>
efidebug boot order 1
<apalos>
bootefi bootmgr
<apalos>
In theory that's all you need
<apalos>
(of replace the kernel and initrd with your own)
<apalos>
-b == the kernel,
<apalos>
-i == initramfs
<apalos>
oh and -s == kernel cmdline
<hays>
what is -b 1 my_OS
<apalos>
that's the name you want to show up
<hays>
bootarm.efi is that a file I need?
<apalos>
you need your kernel image in that (uncompressed)
<hays>
"in" that?
<marex>
hays: doesnt the armada have true HW RNG ?
<hays>
I have Image and a .dtb... no initramfs
<marex>
kabel: ^
<hays>
marex: i haven't been able to find this out, or if it does, how to get it added to the .dts
<apalos>
oh that assumes you are using the default u-boot dtb
<apalos>
I think you can provide the address to your special DTB as the third argument of 'bootefi bootmgr'
<hays>
i am building a dtb with u-boot
<apalos>
that's fine then, just skip the -i option
<hays>
apalos: this is cool, but i am still unclear on how I prepare the efi/boot/bootarm.efi file
<apalos>
hays: you dont
<apalos>
the default Image that your kernel compilation spits out is what you need
<hays>
let me check that
<apalos>
EFI has default names for the binaries it loads, so it can loaded *something* if you havent configured anything
<apalos>
so you can skip the entire efidebug command, since you dont need an initrd
<apalos>
and just name your kernel bootaa64.efi
<marex>
hays: it shoudl be in the base SoC DT, maybe even enabled
<apalos>
oh and efidebug is not enabled by default iirc
<hays>
apalos: wait I just rename Image?
<hays>
marex: its not
<apalos>
ywa
<apalos>
hays: if your bootcommand is "distro boot_cmd" yes
<apalos>
if it's not you need that efidebug command
<apalos>
hays: it's a bit 'weird' atm since not all EFI changes we are planning are done
<apalos>
but the tl;dr is
<apalos>
1. if your device has EFI enabled, your boot command is 'run distro_bootcmd' and you don't need an initramfs just name the kernel bootaa64.efi
<hays>
apalos: i may try this... although its a little scary i don;t want to brick my device
<apalos>
you can't brick it
<apalos>
you are literally not doing anything to your firmware
<hays>
so i think i need that command to set boot args
<apalos>
ok so you dont need an initrd because you have the kernel loading the partuuiid
<apalos>
the bootargs are read and translate automatically with bootefi
<apalos>
so you just need to set those
<hays>
sorry if i am being obtuse.. but it sounds like you are saying ... maybe i dont change anything but the name of the kernel file?
<hays>
or does my bootcmd simplify because its using the u-boot dtb
<hays>
or maybe i need an EFI partition?
<hays>
rather than the ext4 partition i have now?
<kettenis>
you're using the booti command right now
<hays>
marex: I will poke. thanks for the tip
<hays>
kettenis: so is it as simple as bootcmd=mmc dev 0; ext4load mmc 0:1 $kernel_addr_r $image_name; ext4load mmc 0:1 $fdt_addr_r $fdt_name; bootefi $kernel_addr_r $fdt_addr_r
<kettenis>
possibly
<hays>
where $image_name is bootaa64.efi (Image)
<apalos>
hays: yes that bootefi will probably work
<hays>
and this will solve the KASLR issue?
<apalos>
well there's no 'issue'
<hays>
"KASLR disabled due to lack of seed"
<apalos>
it adds an extra level of randomization if you boot with efi
<apalos>
yea that means there's no RNG on your device
<apalos>
EFI ignores the kasrl-seed
<hays>
that appears so.
<apalos>
so you need an RNG device on u-boot
<hays>
i compiled RNG support, but it seems to want hardware support also
<apalos>
yep
<apalos>
there's an EFI_RNG protocol, which the kernel queries on boot
<apalos>
and if you have no device availaible, we dont install the protocol
<hays>
so with or without EFI, KASLR is going to be disabled
sukbeom has quit [Quit: WeeChat 3.5]
ldevulder has quit [Remote host closed the connection]
<hays>
it did not boot this way. "No EFI system partition" maybe is problem?
<hays>
no prob thanks for looking into it... and at any point I can stop. I don't NEED EFI I just figure it might be helpful to track down a possible bug
<kabel>
marex: "doesnt the armada have true HW RNG ?" which armada? 3720 does, but only with CZ.NIC's firmware running in the cortex-m3 secure coprocessor
<kabel>
marex: this needs turrix-mox-rwtm driver in linux kernel
<marex>
hays: ^
<Manouchehri>
ah, does CONFIG_DM_RNG default to n?
<Tartarus>
Yes
<Manouchehri>
that makes sense why it's doing nothing, thanks. Rebuilding now.
<macromorgan>
but for that command the workflow would be 1) load your devicetree into RAM (fatload mmc 0:1 devicetree.dtb); 2) point fdt to it "fdt addr ${FDT_ADDR}; 3) allocate more room for it (fdt resize); 4) run kaslr-seed (kaslrseed)
<macromorgan>
just enable the CONFIG_RNG_ROCKCHIP option
<macromorgan>
I also had to add an entry to the u-boot dts file since Linux doesn't have support for that specific hardware yet, at least the v2 version
<Manouchehri>
hmm, so trying to figure out how I can test CONFIG_CMD_RNG
<Manouchehri>
without a serial console
<macromorgan>
does anyone know (while we're on this subject) if the kaslr-seed and rng-seed can be the same size? kaslr-seed seems to have a defined size as a u64, but rng-seed says it's just parsed as a byte array
<macromorgan>
I can't help you with the serial console, unless you have some dupont wires and a Raspberry Pi or another SBC handy...
<Manouchehri>
hang on, I could pass the result of `rng` as a boot arg
<macromorgan>
if I use a u64 for rng-seed I can use the exact same board_rng_seed() function to also populate the kaslr-seed and remove the need for a specific command to set it (basically cut and paste for CONFIG_BOARD_RNG_SEED)
<macromorgan>
it requires either an upstream A-TF, binary A-TF equal to or less than 1.28, or a binary A-TF greater than 1.28 with reordering/rebuilding the image (the loadable order seems to matter post 1.28...)
<macromorgan>
I am using upstream A-TF, I still haven't tested it with Linux yet but am about to
<cambrian_invader>
it's just setting up some environmental variables
<Manouchehri>
hmm
<Manouchehri>
you know what, I might wait until tomorrow when I'm in the office
mncheck has quit [Ping timeout: 255 seconds]
<kabel>
hays: if you need it in u-boot, you just need to extend the driver to also get random numbers. the driver now lives in board/CZ.NIC/turris_mox/mox_sp.c