<smaeul>
apritzel: correct, lack of crust on H3 is mostly about the tooling around it: different loading method, different PSCI implementation, cannot load firmware from Linux because SRAM A2 is always secure
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
<smaeul>
the firmware itself should be basically the same as H5
camus1 is now known as kaspter
<smaeul>
support for ARMv7 chips other than H2/H3 is also affected by the fact that I don't have any
<smaeul>
the A83T does have an AR100, the A80 does not. https://github.com/smaeul/sunxi-blobs has all of the blobs I'm aware of; the relevant SoCs are whatever those codenames translate to
dev1990 has quit [Quit: Konversation terminated!]
dev1990 has joined #linux-sunxi
<smaeul>
bauen1: BSP code. I think that's where the original names in the wiki page came from as well
<smaeul>
though I didn't find any code actually implementing encryption either, just the references to the header fields/constants
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<smaeul>
oh, apritzel, if your mkimage patches are merged, you'll want to update tools/binman/README to stop complaining about mksunxiboot :)
<apritzel>
smaeul: yeah, good point
<apritzel>
smaeul: thanks for the review, btw!
<apritzel>
smaeul: I just fixed the tools-only build (by creating a separate header file for the SPL/eGON header)
<apritzel>
will fix your comments and will try to send tomorrow
<smaeul>
yeah, that sounds ideal
<smaeul>
I wonder how strict the header verification function should be. should it check the checksum?
<smaeul>
for TOC0 I had it check the RSA signatures and everything, but maybe that's a bit too far
<apritzel>
well, if you have it already that's good, but I wouldn't say it's required
<apritzel>
it would be good though if it could eventually apply the same verification algorithm as the BROM, but this is optional
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
kaspter has quit [Ping timeout: 246 seconds]
apritzel has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
zoobab has joined #linux-sunxi
zoobab has quit [Ping timeout: 272 seconds]
zoobab has joined #linux-sunxi
victhor has quit [Ping timeout: 272 seconds]
night199uk has joined #linux-sunxi
gaston1980 has quit [Quit: Konversation terminated!]
niceplace has joined #linux-sunxi
ddlstwrr has joined #linux-sunxi
DonkeyHotei has quit [Ping timeout: 268 seconds]
camus1 has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
camus1 is now known as kaspter
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 260 seconds]
sunshavi has quit [Remote host closed the connection]
sunshavi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
asdf28 has joined #linux-sunxi
jernej has quit [Ping timeout: 264 seconds]
jernej has joined #linux-sunxi
montjoie has quit [Ping timeout: 260 seconds]
montjoie has joined #linux-sunxi
cmeerw has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
AneoX has quit [Ping timeout: 256 seconds]
AneoX has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
rreignier has joined #linux-sunxi
<rreignier>
Hi! Did anyone tried to use the CSI on H6?
<rreignier>
I have been looking at the manual and the registers seem quite different than the ones used by the sun6i-csi driver.
<bauen1>
KotCzarny: sid is just a number of efuses
<bauen1>
plaes: i figured out how to dump the values using linux, but doesn't `selinux-fel sid` only dump the firts ~32 bytes ?
<bauen1>
and i still need a way of writing
<KotCzarny>
for efuses to be writable some pin has to be supplied voltage
<KotCzarny>
which might not be the case on your board
<KotCzarny>
soc pin, that is
<bauen1>
KotCzarny: it (i think) is wired for both my boards
<apritzel>
bauen1: For the one time I burned an efuse, I just hacked it. Might have been in U-Boot (mw.l), or I injected some code into Trusted Firmware (since that always runs in secure world).
<apritzel>
bauen1: for reading the SID for hacking purposes, I would recommend U-Boot's md.l command
<apritzel>
bauen1: and you can read arbitrary memory locations using "sunxi-fel read" and "sunxi-fel readl"
cnxsoft has quit [Read error: Connection reset by peer]
<bauen1>
apritzel: hm, i wasn't really looking forward to doing the writing by hand, but i guess for the 1-3 times i ever have to write to the sid that will do
cnxsoft has joined #linux-sunxi
<apritzel>
yeah, that was my reasoning as well
<apritzel>
also I figured it would be dangerous to give too easily usable tools to every user
gaston1980 has joined #linux-sunxi
<bauen1>
ah yes, having 20 people with "bricked" boards because they managed to enable secure boot by accident wouldn't be so fun
<apritzel>
bauen1: I think once we have established the whole infrastructure around secure boot, we can think about that
<apritzel>
yes, exactly
<apritzel>
in the past people were asking over email, and I send them code snippets
<apritzel>
with some warnings, but I was confident they would know what they do
<bauen1>
or deestablished secure boot by proofing it can be bypassed easily ...
<apritzel>
that was indeed the outcome in most cases: they moved to some other SoC ;-)
luke-jr has quit [Read error: Connection reset by peer]
luke-jr has joined #linux-sunxi
yann has quit [Ping timeout: 240 seconds]
pg12 has quit [Quit: pg12]
pg12 has joined #linux-sunxi
sensille has left #linux-sunxi [#linux-sunxi]
lucascastro has joined #linux-sunxi
ddlstwrr has quit [Quit: Leaving.]
matthias_bgg has quit [Ping timeout: 265 seconds]
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 256 seconds]
vagrantc has joined #linux-sunxi
damex has quit [Read error: Connection reset by peer]
damex has joined #linux-sunxi
florian has quit [Quit: Leaving]
<asdf28>
can someone explain the following when creating a linux config
<asdf28>
i set "DRM_KMS_HELPER=m" and ran "make oldconfig"
<asdf28>
the line was then removed from the resulting config
<KotCzarny>
some prerequisite is not met?
<KotCzarny>
options often depend on some else option
<asdf28>
then i went to the kconfig file and added a description to this option, Tristate "test test test"
<asdf28>
and when i do this, it works
<asdf28>
KotCzarny yes that's what i thought, but it only depends on CONFIG_DRM which is enabled
<asdf28>
i tried it with other config values as well and i noticed that they only get removed when they have an empty description in the kconfig
<mripard>
asdf28: it's not a user-selectable option, it should be selected by the driver
<asdf28>
i just tried it with another option
<asdf28>
when i remove the Kconfig description of any module, it will get removed from the config when i run make oldconfig
<asdf28>
oh
<apritzel>
asdf28: as mripard said: everything without a string after the "bool" or "tristate" is not visible (in menuconfig, for instance)
<asdf28>
so does that mean that entries without a description can only enabled by a "select" command from another option?
<apritzel>
because it doesn't make sense for a user to select this: you don't WANT the KMS_HELPER, you NEED it, if any of the selected drivers depends on it
tuxd3v has quit [Ping timeout: 240 seconds]
<apritzel>
asdf28: yes
<apritzel>
asdf28: and "M" vs. "Y" should be decided by the Kconfig system: if all drivers/options selecting it are "M", you get "M" for this as well
<asdf28>
i am not sure what module is supposed to enable the KMS helper
<apritzel>
but if only one driver is "Y", the dependency needs to be built in as well, so it becomes "Y"
<asdf28>
the graphics driver i use is mali, it doesn't
<apritzel>
fortunately smaeul's code requires some extra brain work to get it running in the first place
<KotCzarny>
well, hdparm has even more dangerous class of commands 'EXTREMELY DANGEROUS'
<KotCzarny>
(when you try to --fwdownload)
<apritzel>
"VERY DANGEROUS, DON'T EVEN THINK ABOUT USING IT."
<KotCzarny>
i think burning efuses should be classified as 'ULTIMATELY DANGEROUS'
<bauen1>
yeah, just don't worry about it the user will find a way around it
<KotCzarny>
as in, no way to fix if you b0rk
<bauen1>
and if you ever thing you have a fool proof system just grab yourself a bored teenager
<KotCzarny>
or a user with some unrelated problem that has 'tried everything'
tuxd3v_ has joined #linux-sunxi
tuxd3v has quit [Ping timeout: 256 seconds]
tuxd3v_ has quit [Remote host closed the connection]
<bauen1>
smaeul: well, i'm not really sure what happened, but something did
<bauen1>
`sunxi-fel ver` works exactly once and then i think the board just stops responding to fel
<bauen1>
not really sure what to make of that
<asdf28>
i wanted to try the mali_drm driver that is included with the 3.4 kernel, and i have seen that the other DRM drivers enable the KMS_DRM_HELPER option, but the mali driver doesn't
<bauen1>
and it's not booting egon anymore so i suppose it was a success, but i'm not sure why fel has broken
<KotCzarny>
didnt you want to break the fel to make things secure?
<bauen1>
well yes
<bauen1>
just not now
<bauen1>
:D
<bauen1>
might be time to test my stack attack
<KotCzarny>
maybe in secure mode fel expects some authentication first?
<bauen1>
nope
<bauen1>
smaeul: what is the exact h64 board you have (including sid dump if possible) ?
DonkeyHotei has joined #linux-sunxi
niceplace has quit [Ping timeout: 265 seconds]
DonkeyHotei has quit [Ping timeout: 265 seconds]
<apritzel>
bauen1: didn't smaeul mention that sunxi-fel had an issue with secure H6 boards? Related to how the smc call was issued?
DonkeyHotei has joined #linux-sunxi
<bauen1>
oh right
<bauen1>
i thought that was only applied when accessing the sid but it isn't
<bauen1>
apritzel: thanks a lot now it works
<apritzel>
bauen1: so what did you change? Is there a patch somewhere?
tnovotny has quit [Ping timeout: 260 seconds]
<bauen1>
apritzel: i just removed the call to smc
asdf28 has quit [Ping timeout: 240 seconds]
<apritzel>
so not a real fix? Is that due to the runtime check, where we try to figure out if the smc workaround has already been applied?
asdf28 has joined #linux-sunxi
<bauen1>
apritzel: i just commented out the call to aw_apply_smc_workaround
<bauen1>
i'm not really sure why fel doesn't work with secure mode
<bauen1>
might need to reconfigure the gic or cspr a bit to make it work i guess ?
DonkeyHotei has quit [Ping timeout: 240 seconds]
rzerres has quit [Read error: Connection reset by peer]
<apritzel>
I would recommend loading code to SRAM A2
<bauen1>
apritzel: i'm trying to overwrite the stack of sbrom with an unathenticated image
<bauen1>
i don't _want_ precautions :D
<bauen1>
actually, doing a binary search against what size breaks fel is probably a good idea
<bauen1>
oh no, it works
<bauen1>
~128kb toc0 with just the first few magic bytes, a payload and then 0x20020 for the rest can hijack control flow by overwriting some return address on the stack
<bauen1>
pretty sure that's the dream of secure boot (without some tricks) going bye bye
<bauen1>
smaeul: apritzel: i can provide you with the image if you want to test it (requires a pine h64 or a board that has an LED on PL7)
rreignier has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #linux-sunxi
<apritzel>
bauen1: ah, I thought you had trouble running normal FEL mode
<apritzel>
so you are executing unsigned code piggy-backing on some TOC0 image?
<bauen1>
not even piggy backing and not even a valid toc0 image
<apritzel>
ah, was my next question
<bauen1>
basically an oversized blob pretending to be toc0 by faking the first bytes
<bauen1>
then a little payload
<bauen1>
and a lot of numbers pointing to the entry point trying to overwrite the return address on the stack
<apritzel>
so you just need the TOC0 magic to trigger the SBROM code?
<bauen1>
the vulnerable code, yes
<apritzel>
is there any size restriction on the payload?
<bauen1>
i dunno, maybe something like ~100kb
<bauen1>
you can always load whatever you want from the sd
<apritzel>
sure
<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)
ldevulder_ has joined #linux-sunxi
<bauen1>
then storing some sort of secret in memory that is powered by the rtc
<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>
but i don't really think that 0x30 bytes is enough to fix it
matthias_bgg has quit [Ping timeout: 240 seconds]
<bauen1>
ideally i would need some memory that is below 0x20000 so the stack could be moved there, but there isn't any
<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>
but that is a bit impractical
ldevulder has quit [Ping timeout: 246 seconds]
<bauen1>
i wonder if moving the stack a lot higher could help
<bauen1>
oh wait
<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>
but i'm also not sure if 0x30 bytes are actually enough entropy
gnarface has quit [Remote host closed the connection]
gnarface has joined #linux-sunxi
<bauen1>
idk, maybe someone else has some crazy idea on how to salvage this
andy25225 has quit [Quit: Leaving]
gnarface has quit [Quit: Leaving]
<asdf28>
does mali_drm support KMS?
<apritzel>
asdf28: I am afraid you do yourself no favour at all when playing around with this old crap
<apritzel>
(if this is still about this 3.4 AW driver)
<asdf28>
yes it is
gaston1980 has quit [Quit: Konversation terminated!]
<asdf28>
the new drivers do not work very well
<apritzel>
asdf28: but you want that on a newer kernel, right?
<asdf28>
no, i'm using the legacy kernel
_whitelogger has joined #linux-sunxi
psydruid has joined #linux-sunxi
<apritzel>
bauen1: woohoo, so your CPU hotplug idea from last week worked with FEL booting through a 64-bit SPL now!
<apritzel>
I just changed the code that writes the 32-bit entry point, instead of the RVBAR shadow (in CPUR I write the magic and the address into the RTC
<apritzel>
in *CPUX_CFG)
xes_ has joined #linux-sunxi
xes has quit [Ping timeout: 260 seconds]
<apritzel>
or rather R_CPUCFG, according to the manual (0x01f01da4/c)
<asdf28>
after some reading, i came to the conclusion that mali_drm does not contain the required KMS code
<apritzel>
not sure about this old driver, but the display driver (using KMS) and the mali driver are separate things, right?
<asdf28>
yes there is a mali driver and a mali_drm driver
cmeerw has quit [Ping timeout: 240 seconds]
putti_ has joined #linux-sunxi
ElBarto_ has joined #linux-sunxi
lvrp16 has quit [Ping timeout: 240 seconds]
Putti has quit [Ping timeout: 240 seconds]
fevv8[m] has quit [Ping timeout: 240 seconds]
ElBarto has quit [Ping timeout: 240 seconds]
fevv8[m] has joined #linux-sunxi
lvrp16 has joined #linux-sunxi
<apritzel>
the display driver is typically called DE (for display engine) or DE2 (at least in mainline), and is from Allwinner, not ARM, so that's totally separate
<apritzel>
asdf28: yes, that's the display driver, which scans out the framebuffer
<apritzel>
that's the 2D part, if you like
<apritzel>
Mali is a pure memory device, it renders a 3D scene into some piece of memory, which is typically the framebuffer (or could be off-screen as well)
<apritzel>
I am not an expert in this whole graphics stack, but KMS is a framebuffer thing, so it has nothing to do with Mali
<asdf28>
i have seen that in the modern kernel the drivers in the drm folder implement the KMS code
<asdf28>
so i thought the mali_drm driver might provide this functionality
gnarface has quit [Remote host closed the connection]
<asdf28>
but it doesn't, it is too small
<asdf28>
thanks for your explanation
<asdf28>
i am getting too tired now
gnarface has joined #linux-sunxi
Asara has joined #linux-sunxi
<asdf28>
but yes, i do understand why it's not provided by ARM, that makes sense