<schroes>
kholk: but that's not 1st stage bootloader (boot mask ROM) enforcement, it's stage 2 (coreboot+depthcharge), which can be replaced, and is fully open-source
<mps>
schroes: I think it is flash on board
<schroes>
at least MTK chromebooks and most/all Intel ones doesn't require signed 2nd stage (so, what resides in SPI NOR Flash), maybe Exynoses and Snapdragon do
<schroes>
mps: indeed
<mps>
yes, I flashed peach pi chromebook with modified 1st stage bootloader
<mps>
but not 'ready' to do same with oak-elm
<schroes>
mps: just to avoid confusion, in the terminogy I've used above that's 2nd stage, as 1st stage is usually a mask ROM in SoC and can't be replaced
<mps>
schroes: right
<schroes>
mps: your modified bootloader used upstream coreboot? or google's downstream fork? or something completely different?
<mps>
but nowadays terminology is so messed
<mps>
schroes: tbh I forgot what I flashed, but I remember it original flash (2nd stage) with some changes
<mps>
s/it/it was/
<mps>
maybe hexdump0815 could tell more when he come online
<mps>
I'm sure you know that replace mask ROM is not so easy
<schroes>
mps: it can't be practically done, only maybe with a laser on the silicon die and a lot of tries (and broken chips as a result) lol... but why do this, if it doesn't enforce 2nd stage signature? it's tens of KBs at most usually
<mps>
schroes: iirc 2nd stage could be anyhting, I mean any code
<schroes>
indeed, and that's what I'm going to replace, not the 1st stage which is very hard and pointless
<schroes>
you can always read and audit 1st stage from mask ROM if you want, it's always so small because of physical constraints
<schroes>
another possible source of confusion is that by mentioning 2nd stage above, mean the 1st stage doesn't usually verify 2nd stage's signature before running it (on most chromebooks)
<mps>
few years ago (6-7 maybe)someone told me that I can flash modified u-boot which doesn't need to be signed on peach pi
<mps>
but I lost contact data
<schroes>
on some/most SoCs you can enable 2nd stage signature verification by the first stage by provisioning eFuses (and burn the public key into), but anyway on most MTK chips the bootrom's sig verification has been broken (cyrozap, who's not here but on some other channels, published dumps of their boot mask ROMs), so enabling it won't have much sense anyway
<mps>
only remember he worked for samsung
<schroes>
mps: yeah on most chromebooks whatever first flashable stage is, it doesn't have to be signed
<schroes>
you can put small Linux kernel into the SPI flash chip (usually 4MB out-of-the-box), and then kexec() another kernel, coreboot supports that
<schroes>
(or not kexec(), if the small kernel is enough for you)
<mps>
I didn't wanted to risk flashing much because I don't have flashing interface with clips to flash directly on chip
<schroes>
make allnoconfig can help with creating a small kernel which would fit
<schroes>
mps: I have a debugging clip I got for 3eur or so, but for SOIC8, while my current platform has WSON8
<schroes>
SPI flash chip
<mps>
yes
<schroes>
I'll try it, but it's unlikely it'll make any contact despite same/similar pin spacing, so then I'll have to buy a new clip
<schroes>
I simply use an old RPi to flash via a clip
<mps>
but I've got long age u-boot on part1 for my two chromebooks and only don't have it for 3rd one - oak-elm. I don't use chromebooks much nowadays so I don't work to improve them
<schroes>
in the past I did soldering to flash a WSON8 chip on the mobo (ThinkPad X200s), but honestly it was pretty painful (and required very slow flasher speed because of unmatched capacitances and various EMI stuff, anyway, it worked and did what it was supposed to)
<schroes>
better to have a clip
<schroes>
I have oak-hana
<mps>
iirc hana and elm are very similar
<schroes>
it's a really nice laptop, yesterday I've checked out that hardware virt works very well on KVM (wasn't sure because of lacking data on this CPU and ARMv8 specs defining virtualization extensions as "optional)
<mps>
I remember that one alpine co-developer used kernel I made for oak on hana
<schroes>
so probably Xen would work on it, as well
<mps>
schroes: iirc qemu worked on oak
<schroes>
it does, right, with -enable-kvm too
ungeskriptet1 has joined #linux-mediatek
<mps>
and I agree, oak is/was very good notebook so hana is also I guess
<schroes>
some websites are clearly wrong on this SoC... https://www.google.com/search?q=MT8173C+virtualization they claim "virtualization: none" and "AES-NI" (which is an Intel's term/trademark) as none, while this CPU has AES (and sha1, sha2) hardware instructions, it's even reported in /proc/cpuinfo
ungeskriptet has quit [Ping timeout: 264 seconds]
ungeskriptet1 is now known as ungeskriptet
<schroes>
therefore, was happily surprised when HW virtualization ran on it
<mps>
right, I used aes for crypting FS
<schroes>
but practically probably most ARMv8 cpus have virtualization extensions (despite it being defined in ARM specs as optional)
<schroes>
the CPU in RPi3 and newer - same
<mps>
heh, apple M1 support only 64bit KVM, not 32bit
<schroes>
so you can't boot a 32-bit kernel in it?
<mps>
yes, it can't work
<schroes>
isn't armv8 supposed to be backwards compatibile with armv7, also in the context of virt guest?
<mps>
well, apple decided differently
<schroes>
what's the problem there? some memory-mapped values that needs to be set in guest beyond first 4GB of the address space?
<mps>
I didn't looked deeply but guess is they want to save some space on chip and increase performance
<mps>
will guess
<schroes>
mps: BTW, have you ever encountered "cannot enable kvm when guest cpu had el3 enabled" error in QEMU? had it with -machine=raspi0 and raspi3 for example and even setting -cpu=host,el3=no didn't change anything, but -machine=virt worked just fine
<schroes>
I've only booted 64-bit kernels in it so far (on MTK), but later I can try with 32-bit as well
<mps>
no, I didn't, but didn't used RPis for anything, just tested a little few times
<schroes>
nope, it's about setting -machine=raspi3 in qemu
<schroes>
with kvm
<schroes>
on a MTK host cpu
<mps>
ah
<schroes>
how to disable "el3" feature in cpu in qemu, when some -machine settings seem to imply it?
<mps>
have no idea, never tried
<schroes>
maybe I should ask later on some qemu or kvm related channel
<schroes>
also I'm gonna try running Xen on this CPU (with Linux dom0, of course), but I'm expecting it to work, just with no early boot console from Xen (which is also often a problem on some x86-64 EFI machines)
<cyrozap>
schroes: Maybe you're thinking of someone else who published dumps of MediaTek boot ROMS--I've only ever published the hashes of the boot ROMs I've dumped.
<schroes>
cyrozap: nice to see you here! so apparently I've overlooked you on the nicks list
<schroes>
okay, maybe I got confused on the whole dumps thing
<cyrozap>
Also, FWIW, as of four or five years ago (the last time I was really paying attention to this stuff), I'm not sure if anyone's developed an "untethered" secure boot bypass for the MediaTek boot ROMs--all the one's I've seen have only ever targeted the later boot stages (at least as far as I could tell).
<cyrozap>
The boot ROM secure boot bypasses I (and others) have discovered rely on either USB access or JTAG/SWD access.
<cyrozap>
Or fault injection, etc.
<schroes>
cyrozap: can I somehow enable secure boot and burn in my own public key for verification of SPI flash contents on MT8173C?
<schroes>
on HW with unprovisioned secure boot, of course
<cyrozap>
Maybe? I think that requires that power is supplied to the EFUSE programming voltage pin, which is not always connected or broken out, especially if that hardware never had its fuses programmed in the first place. Also, I never bothered to fully reverse engineer the efuse programming code, so I'm not actually sure how it works. Though, I think there's a routine in some of the boot ROMs that
<cyrozap>
supports programming the fuses, so it may be possible to do it by just sending the right USB DL mode command.
<cyrozap>
I don't know the situation for the MT8173, though, since I never dumped and RE'd that boot ROM (I don't own any hardware with that chip).
<schroes>
cyrozap: can I somehow check is the power pin connected on a particular board from software? e.g. with some /dev/mem read, or with some USB command?
<schroes>
I mean, in a way which is known right now, as it's almost certainly possible somehow
<cyrozap>
Oh, also, sometimes the fuses are already programmed. There's some bits in an EFUSE register that says whether further programming is permitted or not, and I know that bit is checked by software, but I never tested whether or not the bit actually disabled anything in the hardware to prevent further programming.
<schroes>
cyrozap: in theory all fuses can be burned (so, set to 0) to prevent any further action :) but that's unlikely
<cyrozap>
If the bits are only ever check by software (and that's a big "if"), then it might even be possible to program bits in the EFUSEs even after "final" programming.
<schroes>
and if the single fuse you're mentioning is burnt, that would require the power pin to be connected on the board, so that may be good news
<cyrozap>
I'm not sure if the EFUSE programming power can be checked from software. That's not to say that it can't be--I simply don't know.
<schroes>
but it's still only guessing
<schroes>
cyrozap: yeah okay, thanks, so that would require some further reverse-engineering
psydroid has joined #linux-mediatek
<cyrozap>
schroes: There's some information on the MT65xx efuse controller starting on page 165 of this datasheet that might help (no idea how much of this would apply to the MT8173, but it's better than nothing): https://archive.org/details/mediatek_202304/MT6516/page/165/mode/1up
<schroes>
cyrozap: thanks for the docs! no datasheet available for MT8173(C)?
<schroes>
also, what's the difference between MT8173 and MT8173C? 2nd set of cores possibly faulty and therefore disabled? pmos wiki is confusing on this
<schroes>
or is wiki completely wrong on claiming that MT8173 has 8 cores (2 clusters of 4 cores)?
<cyrozap>
The datasheet/functional spec for the MT8173 (and many other MediaTek SoCs) doesn't describe the EFUSE controller, unfortunately.
<cyrozap>
Also, I think there's parts of the EFUSE burning process that involve telling the PMIC to enable and disable the EFUSE programming voltage. So, that's another thing that would need to be reverse engineered.
<schroes>
cyrozap: where can i find its datasheet? torrents, archive.org?
<schroes>
this may be more suitable for one of the #postmarketos channels, though, so others engaged in maintaining the wiki can read
<schroes>
on OFTC
<schroes>
cyrozap: I think I'm gonna paste the log of last few messages (starting from my message at 11:07:23 UTC) there (via pastebin), if no-one minds
<schroes>
it's important matter for the wiki
<cyrozap>
Yeah, that's wrong in a lot of places. 1) MT8173 has a PowerVR GPU, MT8183 (a.k.a. MT6771, a.k.a. Helio P60) has a Mali-G72 GPU, 2) MT8173 has 2x A72 + 2x A53 cores, MT8183 has 4x A73 + 4x A53, 3) MT8173 was introduced in 2015, MT8183 was introduced in 2018 or 2019
<cyrozap>
Sure, feel free to paste these messages
<schroes>
cyrozap: just did it, and if anything will follow, we can continue in #postmarketos on OFTC
<cyrozap>
Also, it's important to note that some MediaTek-based Chromebooks have MT8173, while some have MT8183, and some newer ones might have even newer SoCs (I saw activity on the LKML about some newer SoCs a few years ago--no idea if they ever ended up shipping in ChromeOS devices, though).
<schroes>
cyrozap: I have only oak-hana, so it almost surely has MT8173
<schroes>
or MT8173C
<cyrozap>
Yeah, if you have an older Chromebook, it's probably MT8173
<schroes>
cyrozap: it's not this old :) it charges via usb-c, but interestingly negotiates 15V from USB-PD at most, even though my ThinkPad T480 does 20V with the same charger
<schroes>
but yeah that's surely relative is some device "old" or not
<schroes>
that's not a SoC feature though, I think it's EC what handles it all on this platform