macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
mckoan|away has quit [Read error: Connection reset by peer]
mckoan|away has joined #u-boot
LeSpocky has quit [Ping timeout: 240 seconds]
EdSwarthout has joined #u-boot
LeSpocky has joined #u-boot
pratyush has quit [Ping timeout: 272 seconds]
pratyush has joined #u-boot
monstr has joined #u-boot
milkylainen_76 has joined #u-boot
milkylainen_76 has quit [Client Quit]
soumar has quit [Ping timeout: 248 seconds]
agust has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
fdanis_away is now known as fdanis
ccf has joined #u-boot
<ccf>
Ahoj, I want to lock-down an u-boot. The u-boot is getting checked by the SoC-Microcode (secure boot) and the kernel is getting loaded only when the fitImage-Signature passes. So far so good, not I need to lock-down the u-boot so that it's e.g. not possible to load a kernel by bootz oder tinker with the ram by 'mw'-command. Do you have any idea: What is the best way to do? Just disable uart? (Some Info-Messages would be still nice) Only
<ccf>
disable uart-rx-line?
soumar has joined #u-boot
gsz has joined #u-boot
<milkylainen_>
ccf: Depends on who you're trying to fool with "security" :)
<milkylainen_>
I think the only reasonable security measure (not without drawbacks) is to have an unbroken verification from the CPU on all executing code. If you break that chain at any one point with "my own signature", you become susceptible to choices. Sure. You can harden the whole thing to the point of insanity..
alpernebbi has joined #u-boot
mmu_man has joined #u-boot
<clarity>
ccf: You could just disable input from uart
<clarity>
Or console input, whatever you call it
<clarity>
I'd grep for tstc and getc (starting with common/console.c maybe)
tre has joined #u-boot
eduardas has joined #u-boot
tnovotny has joined #u-boot
gsz has quit [Ping timeout: 250 seconds]
gsz has joined #u-boot
gsz has quit [Client Quit]
jwillikers has joined #u-boot
mmu_man has quit [Ping timeout: 250 seconds]
elafon_ has quit [Ping timeout: 240 seconds]
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #u-boot
davlefou has quit [Remote host closed the connection]
<sjg1>
ccf: You can disabled CONFIG_CMDLINE and directly run the logic you want
<sjg1>
ccf: Once we have bootmethod/bootflow landed you won't need the cmdline for common boot flows
tre has quit [Remote host closed the connection]
mripard has quit [Ping timeout: 240 seconds]
mripard has joined #u-boot
monstr has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
eduardas has quit [Quit: Konversation terminated!]
davlefou_ has joined #u-boot
mmu_man has joined #u-boot
fdanis is now known as fdanis_away
<ccf>
sjg1: Thanks for your input. With "directly run the logic", you mean simple plain C platform code and not the built in environment code, right?
<marex>
ccf: against what are you trying to protect the system exactly ? what is the threat model ?
<cambrian_invader>
ccf: just use ENV_IS_NOWHERE
<cambrian_invader>
and of course set BOOTDELAY to -2
macromorgan has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
<ccf>
cambrian_invader: thanks, nice docu!
<ccf>
marex: data integrity, tamper resistance, prohibition of changing data offline and as good as possible online. I'll use dm-verity for the root-filesystem. U-Boot is getting checked because it's inside of a FIP image by the rom-code.
<marex>
ccf: exfil of data too ?
<marex>
which soc is this ?
<ccf>
marex: Exfil, what is that?
<ccf>
marex: It's a stm32mp1
<marex>
read data out
<marex>
mrnuke: ^
<ccf>
no, no need for encryption
<ccf>
can you recommend something?
<marex>
ccf: in that case, just have the bootrom authenticate u-boot spl, have u-boot spl authenticate u-boot fitImage and so on
<marex>
I think mrnuke did implement just that recently
<ccf>
marex: That's what I'm currently doing.
<marex>
you can possibly even have the SPL authenticate fitImage with linux and boot it directly, see falcon mode
<ccf>
But I want to disable the interactivity of u-boot, so that a potential attacker is not able to load just another kernel by bootz (not bootm the fitImage)
<marex>
practical attacker would connect JTAG unless you fuse it off
<marex>
ccf: disable bootz altogether, just use fitImage and authenticate that and nothing else
<ccf>
marex: yeah, I will need that too. Can you recommend something to disable the interactivity of u-boot?
<marex>
well, look at falcon mode, you can avoid starting the u-boot altogether, spl can start kernel directly
<marex>
otherwise what cambrian_invader said, set bootdelay to -2
<marex>
it means no way to enter shell
<ccf>
Ah, okay. So it's not necessary to disable the RX-UART line by mxing it offline?
<marex>
you can enable nulldev uart and point u-boot there if you want to avoid any output
<ccf>
s/mxing/muxing
<marex>
and input ...
<ccf>
I wan to see output, but want to disable input
<marex>
bootdelay -2 is what you want then
<ccf>
TF-A is the SPL loader, so there is currently no u-boot spl
<ccf>
Ok, I go with bootdelay -2, thanks for your input!
<marex>
oh ... I see ... so you have no real security anyway
<ccf>
:) ? why not
<ccf>
I am not aware of that
<ccf>
the ST default "trusted" mode is this: rom-code checks FIP-Image Signature, the FIP-Image contains a TF-A -> OPTEE and u-boot get started. Why is that no "real security"?
<marex>
I have very little trust in the atf development model in general
<marex>
I trust the crypto code in u-boot considerably more
<marex>
and honestly, having a big "lock" icon on the website and calling it "trusted" ... and then pushing developers to install code validation tools using NPM doesn't really help
<marex>
the code review process is also not stellar
<ccf>
:D ... oh I see, most of the SoC are shipping default devkits with TF-A, even NXP on the i.mx8 stuff is doing so
<marex>
yes, with NXP that is particularly problematic, their atf implementation is outdated fork with huge amount of changes and nasty misuse of the SVC interface, so you better "trust" it
<Harm>
But there you load ATF through U-Boot SPL right?
<marex>
Harm: well there you load the PSCI interface implementation really (bl31)
<cambrian_invader>
marex: yesh, but do their bugs show back up later as CVEs? :P
<marex>
cambrian_invader: is that a leading question ?
<ccf>
I haven't checked, is u-boot even able to boot directly by ROM-code, or is there currently always a TF-A, bl-blafoo necessary?
<marex>
cambrian_invader: I still prefer the u-boot CVEs than bugs which I don't know about
<cambrian_invader>
I believe you made that exact remark regarding some of your patches and the recent CVEs with verified boot :)
<marex>
ccf: U-Boot has been around long before ARM started on ATF at all, so ... yes ?
<marex>
ccf: even on the stm32mp1, all the systems we ship are shipped without atf, because on armv7a, psci is optional (and on the mp1, useless)
<Harm>
marex: Right, the imx platforms have a proprietary NXP ROM for secure boot. Not sure if that's better than BL1/BL2 from ATF
<marex>
Harm: HAB is OKish, it just authenticates the next stage
<Harm>
The encrypted boot stuff in the HAB is poorly documented though. I managed to get errors that were not documented. The hab_status command implementation in U-Boot is so horrible that it completely hangs when an unknown error occurrs
<marex>
oh, one more thing, atf is open-source, that means the code (you possibly contributed) can be taken and close-sourced without problem and never released in source, or included in close-source program
<marex>
u-boot is free software, so you always have the right to obtain the code if you have a matching binary
<Harm>
What's the ATF license?
<marex>
also, community development (u-boot) vs. atf (single company) development
<marex>
Harm: BSD-3-Clause
<vagrantc>
mostl BSD-3 clause
<Harm>
ah yeah
<marex>
great for easy consumption by big companies, not so great for regular contributors
<cambrian_invader>
HAB also already had bugs iirc
<marex>
cambrian_invader: yes it did
<cambrian_invader>
which had to be fixed with new silicon
<cambrian_invader>
so take your
<marex>
cambrian_invader: at least with u-boot, a silicon vendor cannot not-provide the sources if you have the binary
<cambrian_invader>
"root of trust" with a grain of salt
<Harm>
iirc in the X.509 parsing. Because you obviously need that in a ROM
<marex>
cambrian_invader: with one of the silicon vendors, they refused to provide atf sources already, so ...
<cambrian_invader>
IMO secure boot is a lot of effort for very little gain for the end user
<ccf>
marex: pretty interesting to get a bit of more knowledge behind the scenes. You said "psci is on the mp1 useless", in the future I want to use optee - I guess you strongly advise against?
<marex>
ccf: talk to mrnuke , he did mp1 without atf and with optee
<marex>
ccf: I only looked very briefly into optee, so I don't have an opinion
<ccf>
cool, I will send him an IM, currently he is disconnected (ZNC IRC bouncer).
<marex>
ccf: mrnuke is in this channel, so just wait a bit
<marex>
cambrian_invader: it is useful if you're manufacturing devices which you need to lock down
<cambrian_invader>
yeah, but that's not in the user's interest :)
<marex>
cambrian_invader: I can see how it can go both ways
<sjg1>
ccf: Yes I mean you call the same code that the commands call
<sjg1>
ccf: There is a way to disable loading the environment too I think
<ccf>
sjg1: yeah, this (no env loading from anywhere other) and bootdelay -2 should be enough.
<Harm>
CONFIG_ENV_IS_NOWHERE
<ccf>
sjg1: so even environment script is possible
<sjg1>
ccf: See should_load_env() - the load-environment config so put it in the /config node in the DT - see doc/device-tree-bindings/config.txt
<marex>
sjg1: it is possible to filter out env variables from external env too, so your machine imports e.g. only one integer from the env
<marex>
but not scripts for example
<marex>
so you can then do things like fw_setenv in userspace, set your integer and do e.g. boot-into-OS-B-copy for AB update
<ccf>
sjg1: So just the default built-in-environment is enought for me.
<marex>
ENV_WRITEABLE_LIST this
<ccf>
by the way, why is it possible to enable CONFIG_ENV_IS_NOWHERE and CONFIG_ENV_IS_IN_MMC at the same time?
<marex>
yeah, the ^ writeable env list uses just that
<marex>
env nowhere for the default env template, and env in some storage from which it imports the select variables
<ccf>
ahhh, ... for AB update, I get it
<ccf>
cool move
<marex>
thats what I used it for, it can be used for whatever other purposes where you only want to import specific variables
<ccf>
so the userland env-set-tool can still be made working, right?
<marex>
avoid strings obviously
<marex>
yeah
<ccf>
maybe obvious, but why is it not a good idea to use strings?
<marex>
ccf: because you can have a string which says "setenv bootcmd go 0xevilcode" or some such
<marex>
say, you do something like this
<marex>
bootcmd=run myscript bootcommand
<marex>
myscript=echo do nothing <-- but you leave this string unprotected
<marex>
then bad actor can do fw_setenv myscript run bad commands
<ccf>
okay, ... but calling "run with "myscript-string-which-I-have-no-idea" is a bad idea
<marex>
on next reboot ... well ... bad commands run within the bootloader shell
<ccf>
so the bad idea is not to use strings but to call them with the interpreter, right?
<marex>
ccf: that's why you should have the default built-in u-boot env contain all the scripts you audited
<marex>
ccf: and only have those scripts react e.g. on integer variables which come from external env
<marex>
like ... bootcmd=test $var -eq 1 && run boot_a_copy ; run boot_b_copy
<ccf>
and in that "ENV_WRITEABLE_LIST" I can define that $var-from-outside is only an integer?
<marex>
var is an integer, if the attacker sets it to whatever, it will either boot A or B copy, but no other damage done
<marex>
if external env from which that var is pulled in is deleted, default value of $var from built-in env is picked, no problem
<marex>
yeah
<marex>
look at CONFIG_ENV_FLAGS_LIST_STATIC
<marex>
"var:dw" is what you want
<marex>
d -- %d , w -- writeable (gets pulled in from external env)