<bauen1>
oh nevermind again, spl does support signed images, it's just hidden and it's massive (seems to add ~36kb :D)
<bauen1>
and it limits the BL2 / spl size to a hard 32kb (minus a few hunders bytes for toc0), and the default u-boot spl takes up most of that leaving just about 472bytes, but doesn't actually have the ability to do signature checking
<bauen1>
so taking another look at what the rtc actually offers, it looks like i can sacrifice the alarm0 and the "crypto" part and have a total of 84 bytes (minus 1 bit) that are preserved, take ~52 bytes to make the sbrom actually secure and i have just about 32 bytes for a decryption key and a replay counter
<bauen1>
smaeul: does 49d98cd549c3e2cb5fa4316e1ed365af4d95d9ba in trusted-firmware-a mean that you've figured out what kind of SPC the H6 has and which peripheral corresponds to which or just what each register does ?
<bauen1>
always great to come back and start second guessing if things even worked in the first place
<bauen1>
turns out the poc i made for exploiting secure boot didn't actually work, so i've updated it to make it work
2020-12-23
<bauen1>
KotCzarny: yes
<bauen1>
KotCzarny: i don't think the FHS actually specifies that /usr/{bin,lib,sbin,...} and their / counterpart have to be directories and have to be seperate
<bauen1>
that makes such devices a lot more "desirable"
<bauen1>
tbh that sounds like a nice idea to fuck with the one correcting your homework
<apritzel>
bauen1: something like that, yeah
<bauen1>
apritzel: so you were trying to "optimise" by putting the first instruction of a loop after the branch that goes back up to save a word of code ?
<apritzel>
bauen1: yeah, *theoretically* that should work, it's just mind-boggling and error prone
<bauen1>
aren't the side effects of that _supposed_ to be invisible
<apritzel>
bauen1: because as a young lad you try to put some *previous* instruction in there, to not waste that slot
<smaeul>
bauen1: the CPU executes the instruction after a branch before branching. you can pretend that doesn't happen by putting a nop after every branch
<bauen1>
apritzel: because some instructions won't work properly unless the next instruction is a "nop" or how should that be understood ?
2020-11-27
<bauen1>
i suppose i could start by writing down everything i've found in some form
<apritzel>
bauen1: you seem to misunderstand Allwinner's engagement in the mainline kernel ;-)
<bauen1>
apritzel: yeah, my idea was to just grep the kernel git log for allwinner emails and put all of them on copy if going through "support" wouldn't work
<apritzel>
bauen1: or try this guy who sent the A100 support to the kernel
<apritzel>
bauen1: thought this mostly didn't last long or went astray quite quickly
<apritzel>
bauen1: try going via TL Lim, he has actual contacts and already established communication in the past
<bauen1>
well go figure why i haven't done it yet
<apritzel>
bauen1: ah, this enthusiasm of yound people someone dealing with Allwinner for the first time :-D
<bauen1>
apritzel: right, which reminds me that i should probably try sending them an email about this glaring hole
<apritzel>
bauen1: which happens, but is typically cleared up in a review, or by asking the right people
<apritzel>
bauen1: in general they seem to miss external input. They have some good ideas, but some things look wrong, like if they misunderstood some ideas
<bauen1>
yeah ...
<apritzel>
bauen1: I would say they missed a security audit ;-)
<bauen1>
they only really missed 2 things: checking the total image length before loading it and verifying the asn.1 length of the outer item before using it
<bauen1>
i mean they did put quite a lot of effort into the sbrom, no off-by-one errors, everything allocated on the stack to avoid using a heap, mostly proper length handleing
<apritzel>
bauen1: yeah, it's not watertight
<bauen1>
it makes sense too since these chips are targeting tv hardware that (might) need hdcp keys
<apritzel>
bauen1: The ARISC is meant to drive them, but they are accessible from the ARM cores as well, and they can be made secure world only
<bauen1>
apritzel: yes, the idea is there (and it's nice), but the implementation is a bit lacking
<bauen1>
apritzel: yes, the idea is there (and it
<apritzel>
bauen1: it looks like Allwinner had this idea of having a "secure" enclave on the chip, with dedicated peripherals
<apritzel>
bauen1: didn't the Megas have some I2C hardware? The first ATxxx didn't, but I think they added it later?
<bauen1>
right, i was still thinking of goold old atmegas :D
<apritzel>
bauen1: and for bitbanging you would need control over the pins, which are controlled by the R_PIO controller, which is also switchable
<apritzel>
bauen1: you *can* bitbang I2C, but it's a pain. The I2C h/w controller still requires some hand holding, but it's much easier to drive from a non-realtime OS
<apritzel>
bauen1: there is traditionally an extra I2C controller dedicated to the management processor
<bauen1>
isn't i2c just done over gpio ?
<bauen1>
apritzel: what is this about a "secure I2C" ?
2020-11-25
<bauen1>
*lol
<bauen1>
well, they do like to copy + paste for their technical manuals lo
<apritzel>
bauen1: again: this is AW, abandon all hope. There is little rhythm or rhyme to their designs
<bauen1>
apritzel: yeah, that's what i was thinking, which is also why i'm a bit confused that "A2" wouldn't work from non-secure but (somewhat) work from secure
<bauen1>
apritzel: did you burn the secure fuse on your H616 ?
<apritzel>
bauen1: first: SRAM A2 is definitely *not* secure on the A64, H5, unless you burn the secure fuse
<apritzel>
bauen1: disregard your understanding of the term "usually" when it comes to Allwinner SoCs
<bauen1>
but the RTC (and possibly other) peripherals aren't necessarily set to secure even though they should be
<bauen1>
usually the SPC, SMC and some cpu configuration registers are marked as secure and the DMA is setup correctly
<bauen1>
apritzel: iirc the SRAM "A2" is the (almost) the only thing correctly marked as secure
<bauen1>
jernej: if FEL is not in secure mode read / write to SRAM A2 will result in 0
<bauen1>
yog: not really, but if the 1 year lifetime figure is somewhat accurate that would probably be enough for my usecase
<apritzel>
bauen1: seems like Conrad has them, it seems to be some kind of standard in the RC model world
<apritzel>
bauen1: I once ordered a bunch of "Micro JST 2.0 2-pin" with 12cm of cables already attached of eBay, fits like a glove
<bauen1>
if you want to prevent a rogue root process from overwriting the kernel to bypass security checks or something like that it works
<bauen1>
KotCzarny: i originally started with thinking about a system with a tpm, but if you have local access you can (almost always) just spy on the bus
<bauen1>
willmore: i'm just trying to get as close as i can get to a system secure against physical access, i.e. defeating MITM attacks ; i kind of adjust my threat model once i figure out a somewhat decent solution to the problem(s)
<bauen1>
willmore: sure we can continue some other time
<bauen1>
so in theory if you have a trusted computer (with a fast processor) and you take your device you want to check to a location where nothing malicious is in e.g. a 30m radius you can verify it
<bauen1>
willmore: i've also done a bit of math, and you could use a (fast) processor to verify that another (fast) processor is within a certain physical proximity, by using the speed of light and the time it takes to perform a signature and measuring the latency
<bauen1>
willmore: networked mitm is a form of a local mitm, you just take the target device and replace it with a fake that relays e.g. display / keyboard from / to the original
<bauen1>
and there's still the problem of a networked mitm attack
<bauen1>
this all still won't really prevent the 5$ wrench to the head method
<willmore>
bauen1, it's more stages than I was thinking of, but it's the same process, so I understand what you mean.
<bauen1>
willmore: how is that more complex ? (perhaps the chip proofing who he is is a bit complex, but basically nothing else than TOTP)
<bauen1>
willmore: in theory you can use all of the 0x30 bytes by writing to code to SID and then pointing the hotplug at the SRAM copy made by the SID
<bauen1>
willmore: it's simpler, the secret in the rtc is used to decrypt blob A, A contains information that can be used by the chip to authenticate itself to you and an encrypted blob B, the user verifies that the chip can proof who he is and then enters the decryption key (password) for blob B
<bauen1>
true lol
<bauen1>
now you still want to enter another password to prevent other attacks or make them more costly, like stealing the system and poking lasers at it
<bauen1>
^ that
<KotCzarny>
bauen1: wouldn't normal encrypted volume suffice then? with password entered during boot
<bauen1>
KotCzarny: of course it's still vulnerable to various side channel attacks or poking lasers at it, but that probably costs more than my attacker can afford (or justify in the case of the local justice system
<bauen1>
thanks
<bauen1>
willmore: i already bough some batteries for ~2.2€ just now supposed to arrive at the 2. december
<bauen1>
the secret would most likely be some sort of decryption key
<bauen1>
KotCzarny: so to clear the hotplug flag (and execute the vulnerable sbrom) you need to unplug the rtc, but unplugging it also erases the secret
<bauen1>
KotCzarny: then a secret key can be stored in the last 0x10 bytes
<bauen1>
KotCzarny: so i've written a tiny bit of code (~0x20 bytes) for the general purpose registers that will copy the sbrom and patch it to make it more secure, then configure the hotplug flags to divert the control flow to this code early on
<bauen1>
KotCzarny: part of that are ~0x30 bytes general purpose and a few flags related to the cpu 0 hotplug mechanism
<bauen1>
KotCzarny: the idea is that the RTC power will "persist" a few bytes of memory
<willmore>
bauen1, oh, yes, that. I've been following that. Excellent work!
<KotCzarny>
bauen1: but doesnt that mean that anyone having access to your board can unplug the battery?
<bauen1>
willmore: i've posted a lot of details here, but basically it's about making a secure system, or "patching" the sbrom
<bauen1>
yeah, but once this semester is over (march next year) i'll have a lot more time and will probably start working / buying proper tools
<willmore>
bauen1, what do you need the battery for?
<bauen1>
and i don't really have any one else to ask right now
<bauen1>
well university is _closed_
<bauen1>
i don't currently have a soldering iron :/
<bauen1>
which was enough for a simple PoC (after 10 tries) but not if i want to test my setup a bit more
<bauen1>
i just need a solution for testing (and maybe "production") that's a little more reliable than trying to force jumper cables into the connector
<willmore>
bauen1, title was: "New Backup CR2032 2032 Battery Wire 2 pin Laptop Motherboard BIOS CMOS Battery With Wire Disassemble Battery" Not sure how many of those keywords will be needed, but it was $1.19 for 5 *shipped*.
<bauen1>
oh nice i didn't remember to check that
<bauen1>
i'm trying to not spend a furtune just on 2 rtc batteries
<bauen1>
well thanks lol
<bauen1>
buZz: sorry, i mean the connector on the pine h64 or pine64-lts ?
<bauen1>
i suspect it's an "jst-ph 2.0" ?
<bauen1>
does anyone know what the connector for the rtc battery is called ?
2020-11-22
<bauen1>
black friday sales probably run half of dn42 lol
<bauen1>
tbh i wouldn't mind that happening
<bauen1>
is it already black friday week or are the local retailers just starting early ?
<bauen1>
but tbh, if i'm already gonna abuse the rtc and patch the sbrom i might as well copy / paste a few nops to reduce the attack surface
<bauen1>
just looking into it if there are maybe some bugs
<bauen1>
*nice
<bauen1>
are thesenice
<apritzel>
bauen1: I don't think we have seen any actual devices with ARMv8 cores having NAND - (which is a good thing!)
<bauen1>
it also looks like for booting from nand the sbrom will first look for an image containing the magic strings "BT0.RRTB", "BT0.DMTB", "BT0.NTAB"
2020-11-21
<bauen1>
e.g. on the H6 SRAM A1 is enabled at reset but you need to work a little magic to enable e.g. SRAM A2
<bauen1>
smaeul: but most importantly to SYS_CFG to enable all SRAM (and probably other components) (or maybe bring them "out of reset"
<bauen1>
smaeul: probably because the hotplug method skips a few register writes related to clocks
<smaeul>
apritzel: bauen1: indeed super standby requires an eGON image. it also must have a length aligned to 1k (which apparently is larger than normal boot)
<smaeul>
apritzel: bauen1: I don't think 0x030000d0 does anything unless the fuse is set, so I don't think you can dump SBROM without it
2020-11-20
<bauen1>
smaeul: the h6 manual too says that the sbrom supports `AES128,SHA256,RSA2048,DES` so maybe the STATUS field isn't unused ?
<bauen1>
and a few power side channel attacks could probably be used to extract the secret too
<bauen1>
could still be used
<bauen1>
with the biggest caveat being that decapsulating the chip (while powered), poking laser at it or perhaps using power faults to bypass the secure boot check
<bauen1>
so in theory all you need is an rtc battery + connector to securely store secrets in the H6 SoC (and similiar too probably)
<apritzel>
bauen1: thanks! is the magic the same, at least? 0xfa50392f?
<bauen1>
apritzel: among other things it sets up a few registers related to clocks and then verifies that some magic (similiar to egon) is (near ?) the pointer
<bauen1>
apritzel: super standby does a lot more than just jump to the address
<apritzel>
bauen1, smaeul: do you know what's the difference between super standby and this CPU hotplug, as far as the BROM is concerned?
<bauen1>
stupid off by one errors
<bauen1>
oh of course copying all of the sbrom instead of just 256 bytes helps a lot /s
<bauen1>
i figured out that mkimage excepts some private keys, `openssl genpkey -outform PEM -algorithm rsa -out rotpk.pem -pkeyopt rsa_keygen_bits:2048` is what i've used
<bauen1>
unless maybe i've miscompiled mkimage in some way for some reason
<bauen1>
smaeul: also it looks like fb3040a0844fbc73f2807bc3353ede9cefad1cd2 in u-boot makes the mkimage step fail
<bauen1>
currently i'm trying `../u-boot/tools/mkimage -A arm64 -O linux -C none -a 0xDEADDEAD -e 0xC0DEC0DE -d test4.bin -T sunxi_toc0 test.img` but that doesn't produce any headers
<bauen1>
smaeul: how can i use the new mkimage to generate a toc0 from a binary blob ?
<bauen1>
oh right, maybe enabling the spc when trying to enter fel breaks things
<bauen1>
but my attack sd doesn't work anymore if i enable my "patching" code, so success i guess ?
<bauen1>
or should i say, fel doesn't come up anymore
<bauen1>
apart from maybe the part that copies the monitor code
<bauen1>
apritzel: well, the code shouldn't try to jump back into the original sbrom, the buffer are still at their "old" location
<apritzel>
bauen1: what makes you think so? I mean it might still contain absolute addresses (for SRAM buffers, initial stack pointer, ...)
<bauen1>
the sbrom should be relocatable ...
<bauen1>
hm, so my rtc code does seem to copy the sbrom to 0x108000 successfully, but when trying to jump to it something goes wrong at some point
<bauen1>
oh nice i'm getting confused because binutils as doesn't read `;` as comment
<apritzel>
bauen1: SRAM A2 should be RAZ/WI (read-as-zero/write-ignore) with the NS bit set (on secure boot boards), at least that's what I got from U-Boot
<bauen1>
but read/writes from fel would be ignored since SRAM A2 is marked as secure ?
<bauen1>
0x108000 up to 0x00117FFF should be usable SRAM, right ?
<bauen1>
kind of ironic since that's what i plan on using to "disable" fel
<bauen1>
and normally breaks the fel
<bauen1>
smaeul: perhaps copying the "fel magic" might do something, since that will skip some code where the fel touches the fel
<smaeul>
bauen1: no, I haven't looked into it, but I blame the GIC setup. probably fixing a GIC register or two in the SMC thunk is all that's needed
<bauen1>
smaeul: do you know why exactly the nbrom fel doesn't work with the `smc 0` trick yet ?
<bauen1>
smaeul: right
<smaeul>
bauen1: no, it doesn't touch the SMC, just the DMA controller, both CCUs, the GIC, and the SPCI
<bauen1>
smaeul: well it does set a few things to secure
<smaeul>
bauen1: that's the "set everyting to non-secure" function. the A64/H5 SBROM does the same when entering FEL
<bauen1>
0x00002d50
<bauen1>
apritzel: on the H6 the SPC (and probably the SMC) are initialised before jumping to fel
<apritzel>
btw, smaeul, bauen1: did you find any secret bit that enables the SCP in the SBROM? Or is this directly tied to the secure fuse?
<apritzel>
bauen1: the SMC was an ARM TZ-380, with some ID registers somewhere, so you might be able to scan for it, or verify its location
<bauen1>
apritzel: true lol
<apritzel>
bauen1: I am afraid at this stage we are happy if we can run something at all, totally unencrypted and insecure ;-)
<bauen1>
apritzel: sadly only the memory location of the SPC / SMC are documented for the h616, no register locations
<bauen1>
apparently there is some form of DRAM encryption, which is awesome
<bauen1>
oh this h616 doc is a gold mine
<bauen1>
in the h616 they actually document offset 0x64 of the sbrom as fel_enter (i.e. offset 0x20 of nbrom)
<bauen1>
smaeul: apritzel: according to the h616 manual the sbrom supports "AES-128, SHA-256, RSA-2048, DES" so the _STATUS flags can probably be used for loading encrypted firmware images
<bauen1>
apritzel: let me check the a64 / h616 docs if they match
<bauen1>
apritzel: yeah but it appears that the h6 has a different spc at least
<apritzel>
bauen1: (SPC and SMC, I mean)
<bauen1>
and the SPC setup of the sbrom is lacking as smaeul noted e.g. the RTC isn't protected allowing privilege escalation
<bauen1>
true
<bauen1>
kind of lacking the docs for that on the H6
<bauen1>
apritzel: ohhh, any links to documentation about the SMC or SPC (Secure Peripheral Controller) ?
<apritzel>
bauen1: sure, that's the easy part: there is a well known SMC, and it's easy to protect the first n KB
<bauen1>
or check if the rom actually sets that up for you
<bauen1>
apritzel: please make sure that the dram you put it in is actually protected by what ever form of SMC (Secure Memory Controller) there is
<bauen1>
just a few more bytes wasted
<bauen1>
another note on the h6 sbrom: it clears almost all bits of SYS_CFG (0x03000000), which seems to be responsible for enabling SRAM
2020-11-19
<bauen1>
anyway i need to figure out how to do that and see if i can't make a little demo with it
<bauen1>
apritzel: and as i've mentioned it gets even better since you can now store a few bytes of replay counters in the nvram ; that makes implementing a secure TEE easier
<bauen1>
apritzel: just checking the bytes could be circumvented, but you can't easily fake the >256 bits of an encryption key
<bauen1>
apritzel: even better you use the secret in the rtc as a decryption key for your real secrets (that are probably bigger than 0x30 bytes)
<bauen1>
(if you ever need to change the rtc battery you can do that while normal power is applied i think)
<apritzel>
bauen1: so you can verify your "really secure" boot later on? By checking the secret in the RTC register? And when you find it, you know that you must have booted through your patches SBROM?
<bauen1>
maybe not the most practical since having any issues with the rtc power supply will erase the secrets, but it would be the most secure
<bauen1>
apritzel: while not loosing boot functionality
<bauen1>
apritzel: so if you try to remove the rtc power the secrets get erased
<bauen1>
apritzel: as a PoC it needs to fit into the 0x30 bytes i get from the RTC, but the end goal would be to burn that code into the sid, point the hotplug entry to the sid sram and store a secret key in the rtc registers
<bauen1>
apritzel: so my goal is to copy the sbrom code to SRAM A2, slightly patch it to limit the total size and then execute it
<bauen1>
apritzel: there is none
<apritzel>
bauen1: or is there some limit on the image size?
<apritzel>
bauen1: but if you go crazy large with your image, can't you still reach the end of SRAM A2?
<bauen1>
moves the stack to the end of SRAM A2 and then "returns" to the sbrom, resulting in the 128kb attack image no longer working
<bauen1>
they might just be accessible to exactly 32 bit writes, but what ever, a bit tedious but it works
<apritzel>
bauen1: don't know from the top of my head how sunxi-fel's "write" is implemented, but those registers might only be accessible by <=32 bit writes, for instance
<bauen1>
for h64, as long as the rtc has power resetting won't boot anything but just enable the blue led
<bauen1>
./sunxi-fel -v -p writel 0x07000100 0xe59f0010 writel 0x07000104 0xe59f1010 writel 0x07000108 0xe5801000 writel 0x0700010c 0xe3a01080 writel 0x07000110 0xe5801010 writel 0x07000114 0xeafffffe writel 0x07000118 0x07022000 writel 0x0700011c 0x17777777 writel 0x070001b8 0xFA50392F writel 0x070001bc 0x07000100 # program hotplug and gp regs with led demo
<bauen1>
yes
<apritzel>
bauen1: but "writel" would work for that?
<bauen1>
that's even documented somewhere
<bauen1>
turns out i just can't use sunxi-fel write to write to device memory
<apritzel>
bauen1: IIRC there are architectural restrictions on where the CPU can fetch instructions from (but I can't find that right now)
<bauen1>
or maybe my code is just broken
<bauen1>
is there some kind of reason why you couldn't execute mmio space =
<bauen1>
hrmp, doesn't look like the h64 fancies executing things inside the rtcs address space
<bauen1>
interesting there's actually a bunch of references to the cpu0 boot hotplug register magic value all over the sbrom, that might be worth investigating
<bauen1>
it's enough to load another stage over a (simplified) serial interface lol
<bauen1>
or maybe 32 bytes
<bauen1>
juri_: i've build a 65c168 (like the 6502) sbc that has ~32kb of ram but due to lack of components no io or rom apart from an atmega that does uart and exposes a whole 8 bytes of rom
<apritzel>
bauen1: they gave the whole PCI root complex exactly a 64K MMIO window
<bauen1>
apritzel: what do you mean ?
<bauen1>
still a mini pcie slot makes a board a lot more useful (but might also be another security nightmare)
<bauen1>
i know
<bauen1>
yes
<apritzel>
bauen1: that's not the H64's fault, the PCIe controller in the H6 SoC is broken beyond repair
<bauen1>
it's such a shame that the h64 doesn't have a (functional) mini pcie slot
<bauen1>
all at the back and quite bright
<bauen1>
but that one might be connected to the emac phy in some way which isn't enabled
<bauen1>
apritzel: there are 3 leds (can't seem to control the "white link led" on PL3 yet)
<bauen1>
the power led on this one is green
<bauen1>
20v will fix any bright led
<apritzel>
bauen1: the old Pine H64 I have has an insanely bright white power LED, looks like TL Lim saved on the resistor
<bauen1>
apritzel: actually the green one might be controllable too
<bauen1>
apritzel: it has 4 leds i think, the green always on power led, 1 blue led and apparently another 2 that i haven't used yet
<apritzel>
bauen1: that's the "new" Pine H64 board, in the RPi form factor, right? So does it still have this annoyingly bright LED?
<bauen1>
KotCzarny: yeah i have an r710, but a) it's a bit too loud (but i think that is the hdds fault at this point) and b) it uses >= 110W
<KotCzarny>
bauen1: best part is low power usage, so they can be on 24/7 without me noticing anything on the bill
<KotCzarny>
bauen1: in my case they also server as a audio player
<KotCzarny>
bauen1: yup.
<bauen1>
KotCzarny: haven't really figured out what i can do with the h64 and a64, but i'll probably hook them up to an hdd or ssd and use them as servers for stuff with low requirements and maybe as build server
<bauen1>
KotCzarny: my end plan is to buy an actual rack (somthing like 12u) just so i can keep all my hardware and networking stuff somewhat tidy
<apritzel>
bauen1: lol, this is my plan for years, but this "don't need direct access to them anymore" point just doesn't want to come ;-)
<bauen1>
before i remembered that i can just hook the power up to the uart usb i tried taping some wires to a coin battery that i've salvaged from the motherboard that was in the 1u firewall appliance that i want to turn into a "case" for the h64 and a64 once i don't need direct access to them anymore
<bauen1>
meaning that my crazy idea is probably possible
<bauen1>
so attaching an rtc "battery" to the h64 does in fact preserve the general purpose but also the boot hotplug flag and hotplug entry address
<bauen1>
apritzel: nice, i heard the part about the engagement somewhere before
<apritzel>
bauen1: we don't want to give the impression that missing engagement from a SoC vendor is compensated by Arm
<apritzel>
bauen1: in my spare time, it's merely tolerated at work
<bauen1>
apritzel: by the way are you doing this in your free time or at work ? (looking at your arm.com email address)
<bauen1>
apritzel: nice
<apritzel>
wens: thanks! kudos go to bauen1 for mentioning the "hotplug" BROM facility
<bauen1>
at least i think the sbrom is fully relocatable
<bauen1>
and then you could also store a replay counter in the rtc too
<bauen1>
then burn a bit of code into the sid that copies the sbrom e.g. into some SRAM (e.g. CSI SRAM) and then patches the memcmp8 functions that verify the magic to also set the toc0 header length to a fixed value might work
<bauen1>
since the sid seems to load the efuse contents into memory on reset i think pointing CPU_SOFT_ENT_REG0 towards that and using the 0x20 - 0x30 bytes as encryption key or as secrets could work
<apritzel>
bauen1: so thanks for your help on that. For the H6 those registers are in the RTC?
<bauen1>
apritzel: that is good to hear
2020-11-18
<apritzel>
bauen1: woohoo, so your CPU hotplug idea from last week worked with FEL booting through a 64-bit SPL now!
<bauen1>
idk, maybe someone else has some crazy idea on how to salvage this
<bauen1>
but i'm also not sure if 0x30 bytes are actually enough entropy
<bauen1>
in theory you could store secrets in the 0x30 bytes general purpose registers of the RTC, point the cpu 0 bootflag entry into the SID SRAM copy and write "a lot more" code into the SID that fixes up the SBROM before executing it
<bauen1>
oh wait
<bauen1>
i wonder if moving the stack a lot higher could help
<bauen1>
but that is a bit impractical
<bauen1>
i mean if you never plan on rebooting / powering off the sbc you can always just store an infinite loop in the rtc to prevent the sbrom from running without erasing the secrets
<bauen1>
ideally i would need some memory that is below 0x20000 so the stack could be moved there, but there isn't any
<bauen1>
but i don't really think that 0x30 bytes is enough to fix it
<bauen1>
that way you can hopefully make the sbrom secure enough and still have space to store a secret (that would be used to decrypt the sid) that would be lost if you ever remove power from V_RTC
<bauen1>
then storing some sort of secret in memory that is powered by the rtc
<bauen1>
so far my best idea would be abusing the cpu0 hotplug flag in the rtc to redirect control flow, before the sbrom really executes anything, into a tiny bit of code that is safed in the rtc general purpose registers (0x30 bytes)
<bauen1>
you can always load whatever you want from the sd