<smaeul>
jernej: IIRC the initial sy8106a voltage reads so low because it is in hardware (resistor) control mode, so the field is not used
<smaeul>
awenth (if you're reading logs): I added the H5 SBROM status/error codes to the wiki here: https://linux-sunxi.org/SBROM
<smaeul>
I just tried on my own orangepi zero plus and it failed RSA signature verification, so I must have broken something for H5
<smaeul>
currently there is nothing that you need to set in menuconfig. once I clean up the hacks for patch submission, there will be a Kconfig option to select between eGON and TOC0
vagrantc has joined #linux-sunxi
<smaeul>
I found the issue. One of the questionable things that the H6 SBROM's ASN.1 parser does, is not questionable, but simply wrong, in H5
<smaeul>
So now I will have to modify the code to generate even more malformed ASN.1. At this point, it's not even worth using openssl anymore
<smaeul>
(for anyone who's curious: H6 cuts off the first byte of odd-length integers/bitstrings. however H5 forgets to increment the pointer, so it actually cuts off the last byte.)
ftg has quit [Read error: Connection reset by peer]
hallyn has quit [Remote host closed the connection]
awenth has joined #linux-sunxi
tnovotny has joined #linux-sunxi
hallyn has joined #linux-sunxi
<awenth>
smaeul: Thank you for the tremendous work you're doing. I've used the A33 in a custom tablet of which 2000 was produced. Running Linux& Android. The H5 is a real beast at an affordable price. If the trusted boot sequence can get into mainline it could start to offer some competition to the i.MX again
<apritzel>
awenth: keep in mind that the whole secure boot sequence is probably busted on many Allwinner SoCs
<gamiee>
apritzel: because it can be bypassed by FEL ?
<apritzel>
awenth: at least on the H6 there were proven to be BROM bugs (stack overflow, I think), which allow unsigned images to be booted, despite the secure fuse and a key hash burnt
ats_ has joined #linux-sunxi
<apritzel>
gamiee: FEL is yet another problem, but this ^^^ was an attack using a fabricated TOC0 image on an SD card
<gamiee>
apritzel: well, then secure boot in (most likely) all Allwinner SoCs basically useless, since it's kinda easy to bypass, or?
Mangy_Dog has joined #linux-sunxi
<apritzel>
gamiee: exactly
ats has quit [Ping timeout: 480 seconds]
<apritzel>
having TOC0 support in mainline is still somewhat useful, for those boards that have the fuse burnt, since it allows bigger SPLs, and it enables the SPC on newer (64-bit) SoCs
<apritzel>
(SPC=Secure Peripheral Controller, which allows devices to be made secure-only, so Linux cannot possibly access them)
<apritzel>
at the moment, despite Trusted Firmware living in secure SRAM for instance, Linux can actually overwrite it :-(
<apritzel>
this is "fixed" when "secure" boot is enabled
<awenth>
apritzel: I was hoping that burning the USB OTG port would at least prevent access to FEL fallback and render the device inaccessible.
<apritzel>
awenth: yes, somehow disabling OTG would prevent *this* attack
<apritzel>
but the BROM bugs still remain, and are independent of FEL
<awenth>
apritzel: If an attacker uses a clever constructed SD card to expoit a bug in the BROM, they could possibly read back the eFuses. How would that help them to alter the valid SD card image to do something "unintended"? If they write new eFuse values (0xFFFFFFF) and overwrite the TOC0 signature on the SD card they can probably get it to boot an altered SD card?
<gamiee>
awenth: it's not possible to change efuse once it's burned, that's why it's named eFuse
<gamiee>
(but I can be wrong)
<awenth>
gamiee: I think it cannot be set back to 0, but not sure if subsequent writes are allowed to flip the remaining 0's to 1's Not that anybody would want to brick his device like this intensionally
<gamiee>
awenth: well, changing fuses doesn't help you (unless you will be very very lucky), but since you will do stack overflow exploit, you can execute whatever you want, thus you can skip encryption check and run your own firmware directlz
<awenth>
gamiee: Thats very frustrating. Its a pity that Allwinner didn't publish the BROM for review so that it can be scrutinized to prevent these ever present stack overflow exploits
<gamiee>
awenth: well, it is. Also, Allwinner would never publish their BROM code. Why? Because why they should? BROM is "burned" into the SoC, so you can't change it + in "security terms", it's easier to find stack overflow in source code (and exploit it) than reverse engineering the BROM blob
<gamiee>
but well, this also happens to bigger players like nVidia (one of the first exploits for Nintendo Switch was buffer overflow in BROM in flashing part)
<apritzel>
awenth: with the BROM bugs you can boot whatever you like on the hardware, you don't need to touch any fuses
<apritzel>
awenth: if that allows you to compromise or decrypt an existing image is another question, but typically only allowing only signed software to boot is the major reason for secure boot
<apritzel>
for the fuses: you cannot burn them back to "1", but you can turn all rotpk hash fuses to "0", which reportedly disables the signature check
<apritzel>
which means you can now officially boot *any* TOC0 image, regardless of the key used
<apritzel>
this allows you to "free" a device again
<apritzel>
also there are reports of an extra fuse to turn the whole secure boot off again
<awenth>
apritzel: Would you use FEL access to manipulate the fuses or to load an app that does that? I've just checked that on my board with fuses set, I can load and execute an unsigned app over fel. Surprisingly, loading the TOC0 version of the app did not run over FEL
<apritzel>
awenth: using sunxi-fel?
<awenth>
apritzel: yes
<awenth>
apritzel: Dang, so the whole TOC0 security is busted. Any other way to add an external element to the board, say, over I2C or SPI, to bring hardware in the loop security to your application?
<apritzel>
awenth: sunxi-fel does not support TOC0 images atm, though this is might be added in the future
<awenth>
apritzel: I'm always wary of encrypted applications - With DVDs the CSS key was stored on the disk and as soon as the layout was figured out the whole security model collapsed. I presume there's no way to store a key securely on the Allwinner
<gamiee>
awenth: I seen some "secure SPI flashes", but I think it will be easy to bypass.
<gamiee>
awenth: exactly, but still you can use it to disallow "not that much skilled people" to tamper with your software (since, not everybody know how to use FEL or modify TOC header to exploit into device)
ftg has joined #linux-sunxi
chalesyu has joined #linux-sunxi
<awenth>
gamiee: I'm worried about someone posting a little precompiled app, like DeCSS, that was used to decrypt DVDs enmass. Maybe its a pipe dream, looking at the industrial scale at which the PSP & Xboxes are cracked.
chewitt has joined #linux-sunxi
<gamiee>
awenth: it's possible. Well, then you probably need to use SoC which can offer you reliable secure boot
<karlp>
or, consider whether your revenue model _actually_ depends on this or not.
<karlp>
you _could_ spend time delivering features, or you could spend time trying to prevent things from happening...
<apritzel>
yeah, good point karlp. At the end of the day this Nintendo Mini console for instance didn't really suffer from being crackable
<apritzel>
gamiee: awenth: tampering with "software" is another thing, I believe
<apritzel>
this "TOC0 secure boot" is about to disallow boot of unauthorised code
<gamiee>
apritzel: well, that's true, although, with secure boot, you can "hide" encryption key into the efuses, and encrypt whole SPI/eMMC/whatever (at least for me this is most effective solution to disallow 'tampering")
<apritzel>
yeah, this is probably linked: once you can boot something, you can access the fuses
<apritzel>
although not sure that is fully true, there might be a separate fuse to prevent that
<apritzel>
(but then the BROM might not be able to access that, too)
chalesyu has quit []
chalesyu has joined #linux-sunxi
chalesyu has quit [Remote host closed the connection]
chalesyu has joined #linux-sunxi
chalesyu has quit []
nosliot has left #linux-sunxi [#linux-sunxi]
zumbi has joined #linux-sunxi
<awenth>
apritzel: Well, I think its worth tinkering away to hopefully get to a point where even with the current flaw the system as a whole can be made sucure. Can the OpenRISC co-processor be of any help? With its software also stored as part of u-boot (crust/SCP), an attacker can probably construct an app to neutralise any help that it could provide
Guest1227 is now known as ndufresne
<apritzel>
awenth: the ARISC is in reset when the BROM starts, so I don't think it could be used to improve the situation
<gamiee>
awenth: I would say that it's lose of time looking for other ways of secure boot. If secure boot mechanism integrated in SoC doesn't work, I think nothing else will be better
<apritzel>
awenth: also: how dependent are you really on secure boot? what is the threat that you are protecting against?
<apritzel>
I guess if you really rely on it, I wouldn't take an Allwinner SoC
<apritzel>
not only because of the known flaws, but because this is not well researched territory
<apritzel>
so think about we wouldn't know about those bugs (yet): You would ship it, then be "disappointed" later
<gamiee>
apritzel: researched in what terms?
<apritzel>
as in: independent groups tried to attack this
<apritzel>
I think other SoCs see much more scrutiny here
<gamiee>
ahh, that's true
chewitt_ has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
choozy has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt_ has quit [Ping timeout: 480 seconds]
<gamiee>
btw (offtopic), from what I've seen, looks like H616 isn't much upgrade. Like, H6 was released 4 years ago, and they upgraded only GPU, added one EMAC, and "hacked" MMC controller? (and removed USB3 and PCIe) Or is there anything interesting added in ?
<apritzel>
gamiee: not really, but it supports more than 3GB of DRAM
<apritzel>
and MMC0 (SD card) can be switched internally to 1.8V, so we should be able to use UHS modes and get beyond 23 MB/s
<apritzel>
gamiee: AW is not really in the game of providing the best possible features and performance, they seem to address certain markets and provide a tailored chip for that, for a very small price
<apritzel>
the T723 looks quite interesting, but I remain sceptical about when it hits the market and how they mess it up :-(
<gamiee>
apritzel: Allwinner announced a lot of promising SoCs, but I seen like one which was already publicly released (A100 if I remember?) and it wasn't much "wow"
<gamiee>
about H616: well, still not much interesting upgrades (at least for me)
<apritzel>
yeah, as I said, they are not very impressive, but apparently fit the bill for their customers
<apritzel>
to provide the cheapest possible TV box / dash cam / smart speaker / ...
<gamiee>
about AW's SoCs: well, yeah, but mostly, from what I see recently, even the price of their SoCs are low, I still see less and less products using them.
<gamiee>
I don't know where Allwinner would be today if there wasn't sunxi community.
<apritzel>
gamiee: I don't know if that really plays a big role for their business
<apritzel>
I'd guess many chips go into deeply embedded products
<apritzel>
so consumers wouldn't know about this
<apritzel>
and also we don't know much about the China market
<apritzel>
it could sell fantastically over there, and you wouldn't notice in Europe or the US
<apritzel>
keep in mind that those dev boards are just a by-product, because those chips are cheap and AW sells them in small quantities
<gamiee>
Well yeah, that's true, who knows what situation is in China. But I see (in Europe) mostly Rockchips (car headunits), Amlogic (TV Boxes) and HiSillicon (IP cameras). Also in Aliexpress, there is really not that big amount of Allwinner equiped products.
<apritzel>
at the moment I see a lot of TV boxes on eBay with the H616, but yeah, that's about it
<gamiee>
btw, is there any V831 devkit available, not counting MAIX, and with SDK?
<jernej>
speaking of security - beware of adding "su" to bootargs - that's easy way to get root (at least it was)
<smaeul>
apritzel: yes, there is a write protect eFuse which you can use to prevent further changes to the ROTPK hash / BROM config
<smaeul>
the ARISC could be used to persist a rootkit (it can reset the rest of the SoC without resetting itself, and it controls the CPU entry point, so it could shadow the BROM or runtime patch other firmware), but that's the only way I can see it as relevant to security
<smaeul>
if an ARM CPU is on, it can do all of the same things as the ARISC. there's no security boundary between it and EL3