<plaes>
regarding my performance woes with a64-olinuxino.. now that I managed to get Lima to work, some of the heavy-lifting is now handled by GPU and device is a lot more stable
<plaes>
power consumption is ~5.5W (5.5V / 1A)
<libv>
so it was not the gpu doing something untowards
<plaes>
previously it peaked up to 1.2A
<libv>
so you would need to limit all core power draw in some way
<bauen1>
if the chip doesn't melt, then the temperature is fine /s
<KotCzarny>
what if it melts world around it ?
<bauen1>
it seems that i can actually get the spl to do the most important buisness completely in sram, the stack and bss section aren't that big
<bauen1>
KotCzarny: the chip is fine, so i don't see a problem here
<apritzel>
bauen1: how big is the SPL then?
<bauen1>
apritzel: 61456 spl/u-boot-spl-nodtb.bin
ScrumpyJack has quit [Quit: Eat more sushi]
<bauen1>
plus `288 dts/dt-spl.dtb` and maybe 1-2kb overhead from the toc0
ScrumpyJack has joined #linux-sunxi
<bauen1>
but i think the spl is still loading the u-boot fit image into dram, which is bad
<bauen1>
it is a nice ~700kb, so some size reduction is necessary before i can think about puttint that into sram
<apritzel>
bauen1: ???
<apritzel>
bauen1: the whole point of the SPL is to enable DRAM, so that it can load the actual U-Boot
<apritzel>
bauen1: I think we switched the way the FIT image is created, from external to embedded
<bauen1>
apritzel: i don't care about u-boot being in dram, i just don't want secure-world stuff touching dram without integrity checks / encryption
<apritzel>
originally the FDT part of the FIT image was pretty small, and the payloads were located *after* the end of this DTB blob
<apritzel>
now the payloads are directly in the properties, which makes the actual DTB blob as big as the whole image
<apritzel>
bauen1: (if that was your concern)
<bauen1>
724
<bauen1>
ops
<bauen1>
yes, u-boot makes up about 565kb of the entire fit, so if i can move that out of the way in some form that would be awesome
<plaes>
fun.. arm64 defconfig:
<plaes>
# CONFIG_SND_SUN50I_CODEC_ANALOG is not set
<plaes>
# CONFIG_SUN50I_IOMMU is not set
<plaes>
and also # CONFIG_PHY_SUN50I_USB3 is not set
<bauen1>
why does u-boot have any form of support for the IOMMU ?
<plaes>
this is linux defconfig
<bauen1>
apritzel: i suppose i'm kind of (ab)using spl as better boot rom that supports proper signature checks
<apritzel>
bauen1: I understand that part, but still not sure what your concern is
<apritzel>
I mean you can load and verify everything from the SPL, and then only continue if all checks pass
<bauen1>
apritzel: you mean of keeping everything in SRAM or still using the SPL ?
<apritzel>
I mean the SPL is the loader in our case, so you load the various images, into wherever they need to go (DRAM or SRAM), and verify them, with SPL code
<apritzel>
and then at the very end you jump to the entry point of the next image (TF-A in our case)
<apritzel>
if any of the checks fail, you stop with an error message
<bauen1>
apritzel: thanks for reminding me, i need to check if it copies first and then verifies or the other way around
<apritzel>
plaes: that's correct, that's defconfig for the kernel, not the config a user would use on a production system
<bauen1>
apritzel: i don't want to have the image in dram being modified after it has been verified but before it's being copied and jumped to
<apritzel>
plaes: because the *distributions* should provide a well balanced and tested config
<plaes>
ah.. ok
<apritzel>
bauen1: but there is no code other than your SPL running, and you just checked that every component is trustworthy, before jumping away to the next image
<plaes>
apritzel: although, i2s for sunxi is enabled ;)
<apritzel>
plaes: well, it is enabled what people sent patches for
<plaes>
should I send the patch for CONFIG_SND_SUN50I_CODEC_ANALOG=m ?
<apritzel>
plaes: so defconfig is meant to be some sane (more or less basic) config that all developers can test against, and that should at least boot on some common machines, without requiring modules for the essential part
warpme_ has joined #linux-sunxi
<apritzel>
otherwise you have the issue that every developer tests a different config, and this becomes a hassle to coordinate and verify
<bauen1>
apritzel: i assume that the attacker can modify/read dram with very low cost, but accessing sram is a bit harder
<apritzel>
bauen1: are you sure you are not too paranoid here? If you are worried that people can attack and intercept a BGAed DRAM, then I am not sure using an Allwinner chip is the right solution to begin with ...
<bauen1>
apritzel: yes i am too paranoid, but it's fun and risc-v isn't quite in my price range yet
<bauen1>
there
<bauen1>
*there's always the 5$ wrench crypto bypass
netlynx has quit [Quit: Ex-Chat]
<apritzel>
not sure why the ISA would make a difference, but I was more thinking about SoCs actually properly designed for security, I think NXP has a good reputation here, for instance
<bauen1>
also removing bga chips doesn't strike me as very complicated, soldering on an fpga connector or something like that might be (https://youtu.be/zdvvk0NdAy0?t=218)
<bauen1>
apritzel: i would love to have a "secure" system containing only libre open source components, but currently i'm a bit on a budget so i might as well experiment with some cheaper chips and see how far i get
<bauen1>
though i must say that the arm isa is also very appealing
<apritzel>
sure, starting easy makes sense, but I am not sure this level of physical access is reasonable to protect against then
<bauen1>
but yes, generally it's a bit of a pointless exercise
<bauen1>
apritzel: i've defined my threat model to have sort-of physical access but with some pretty big restrictions on what you can do to the SoC itself, which does make it rather pointless
<bauen1>
at the end of the day it's all a matter of how much money or wrenches the attacker has
<bauen1>
a tiny bit of power glitching will probably get you past the SBROMs certificate check too
asdf28 has quit [Ping timeout: 268 seconds]
<apritzel>
mmh, I would think a threat model is there to draw clear boundaries on what's possible, and power glitching is surely quite a difference from unsoldering and intercepting DRAM
* apritzel
just sees how much difficulty we already have to properly *setup* the DRAM controller for normal operation ;-)
<bauen1>
lol
<bauen1>
apritzel: including physical access in a threat model is quite difficult due to how many things you could potentially do
<apritzel>
I totally agree, but I would still say limited time physical access (being able to hook something into the power supply while the guy in on the loo) is different from being able to pull out the tools needed to unsolder BGAs ...
<bauen1>
ah i see
<bauen1>
but even for power glitching you want to be as close to the target to make things more reliable
<apritzel>
but in general I am too much of an engineer to think about attacking things, I'd rather make them work ;-)
jstein has quit [Quit: quit]
<bauen1>
ugh, the spc on the h6 is kind of weird, i think i've found the register responsible to set the secure / non-secure mode, but i can't get it to work reliably and i also can't find the exact bit responsible
<bauen1>
huh, this is funny, the more often i rebuild uboot, the larger the resulting binary seems to get :D
<bauen1>
u-boot really is the best
hlauer has quit [Ping timeout: 265 seconds]
juri_ has quit [Ping timeout: 265 seconds]
juri_ has joined #linux-sunxi
cmeerw has quit [Ping timeout: 258 seconds]
The_Loko has quit [Quit: Leaving]
Mangy_Dog has quit [Remote host closed the connection]