<samueldr>
somehow shoe-horning this into a usb gadget could be useful to share a device folder
<samueldr>
it basically "wraps" a directory with a filesystem, and maps the block device operations back to file operations
<clever>
samueldr: ive seen some micro-controllers that emulate a fat32 fs on mass-storage, but then map all writes to a .bin file, into writes to its own flash memory
<clever>
so attempting to copy a foo.bin into the "mass storage" will re-flash the firmware of the chip instead
<samueldr>
yeah, seen that too
<clever>
but, that likely relies on the os trying to overwrite fat32 blocks in-place
<clever>
so if your os is trying to be more zfs-y, or your editor writes to a temp file, then renames
<clever>
then unpredictable things can happen
<clever>
thats kind of why old android made the msd exclusive, so internal lost access, and why mtp came about
<samueldr>
not because of that
<samueldr>
well
<samueldr>
yeah
<samueldr>
I misread you
<samueldr>
I thought you implied that old androids implemented a similar scheme of a fake FAT
<samueldr>
which would have been interesting
<clever>
old android just umount'd and then exposed the raw block dev
<clever>
so you loose internal acess to it
<clever>
modern android uses mtp to expose it as an fs, rather then a block dev
<samueldr>
yep
<clever>
something else i was wondering about
<clever>
could you delete 90% of the partition mess on a modern android device?
<clever>
once you can reflash the bootloader, make it more like an rpi?
<clever>
just a boot partition, and a rootfs?
<samueldr>
"once you reflash the bootloader"
<samueldr>
eek!
<samueldr>
for our security the bootloader is signed and checked
<clever>
for some of them, the bootloader is just a blob on the eMMC
<samueldr>
both on MTK and QCOM at least it's not something we can play with, sadly :(
<samueldr>
modifying the partition layout is feasible, but probably unwise
<samueldr>
because if you mess-up one time, you're done
<clever>
isnt that what the mask-rom recovery is for?
<samueldr>
unless you have the programmer program signed by the OEM (and possibly telco)
<samueldr>
yes
<clever>
or are those tools not public?
<samueldr>
not public
<samueldr>
mostly
<samueldr>
though some OEMs did or do share them
<samueldr>
e.g. oneplus and xiaomi
<samueldr>
xiaomi did
<clever>
yeah, i can see how that can be an issue
<samueldr>
oneplus does
<clever>
for the broadom chips, we have usbboot
<samueldr>
(or maybe did, haven't checked)
<samueldr>
I may at some point validate that I can reprogram the oneplus3 and make it a repartitioned device with some goodies
<clever>
ive seen somebody complain recently about how android has 39 partitions, lol
<samueldr>
I *think*, but can't verify, that the boot logo shown early during boot is actually not signed and verified
<clever>
but as long as the one the bootloader wants, still exists, you can delete the rest
<clever>
depending on how the partition table is actually managed
<samueldr>
the ones the bootloader chain wants**
<clever>
is there a header explaining it, or is it just a list of offsets that every tool agrees on?
<samueldr>
and oof
<samueldr>
complaining
<samueldr>
if only they knew
<samueldr>
two tracks
<samueldr>
1) we're getting partitions in partitions now on android 10+
<clever>
lol
<samueldr>
and not defined as an MBR or GPT, but as a list of spans in that partition
<samueldr>
this is to allow brick-less repartitioning of the system/oem stuff
<samueldr>
2) newer qualcomm devices can come with hardware partitioned eMMC
<clever>
so its a custom partition table type, basically?
<clever>
for the inner partitions?
<samueldr>
so you get 5 "block devices" which is the same device, with a mess of partitions in each block devices without rhyme or reason!!
<clever>
what about the outer ones, where the bootloader/recovery live?
<samueldr>
clever: it's something the kernel already supports
<samueldr>
for the outer one it stays GPT
<clever>
how does the mask rom know where the bootloader lives in the flash?
<samueldr>
I don't know, but I always assumed GPT partlabel
<clever>
ah
<clever>
from what ive seen around, allwinner based mask rom's are as dumb as a sack of bricks, and just load a blob from an offset
<samueldr>
the maskroms of recent qualcomm devices even support a/b for the "xbl" (uefi bootloader)
<clever>
and the rpi mask-rom expects an MBR table, with the right type-code, and a fat32 fs
<samueldr>
not *that* dumb, but mostly yes
<clever>
and then a bootcode.bin within the fat32
<samueldr>
a couple offsets, like literally the meaning of couple, 2
<clever>
lol
<clever>
which 2 offsets?
<samueldr>
and it does support eMMC, SD cards, and SPI
<clever>
according to some notes in github issues, the rpi mask rom can boot from:
<samueldr>
>> Newer SoCs (tested on H2+, A64, H5, H6) can also load the SPL from sector 256 (128KB) of an SD card or eMMC, if no valid eGON/TOC0 signature is found at 8KB (BROM boot order). The U-Boot proper offset needs to be adjusted accordingly in this case. U-boot patch more details
<clever>
* (newer models) usb-host, via mass-storage or usb-ethernet+tftp
<clever>
for the rpi 1-3 and compute modules, only the SD and usb-device are enabled, and sometimes usb-host
<clever>
the roku2 (using rpi1 silicon) is also pretty much confirmed to boot from nand flash, but with an unknown layout
<clever>
the rpi4 can boot from 3 sources, SD, spi, or usb-device, and likely supports more but are disabled
<samueldr>
I wonder if they have different mask roms
<clever>
ive heard rumors that the rpi1 is a stock broadcom chip, right off the shelf
<samueldr>
I kinda assume it makes sense for that to exist
<clever>
but the rpi2 and onwards where customized at the request of the rpi foundation
<samueldr>
I was thinking also from roku
<clever>
i heavily suspect that the roku2 and rpi1 use the identical mask rom
<samueldr>
maybe a stock, but different "secure" mask rom?
<clever>
the RE work ive done, say that the hmac-sha1 key, is based on a combination of a constant in the rom, and a semi-constant in OTP
<clever>
for the roku2, every device has a unique per-device key in the OTP
<clever>
so it must sign its own firmware when reflashing itself
<clever>
and if you dont know that key, you have zero way to unbrick it
<clever>
you also cant make a generic image to flash onto the nand, and crack them all open
<samueldr>
it's nice when you see something secure, but it's also saddening :(
<samueldr>
"secure" here means closed
<clever>
in the case of the roku2, the arm is able to read that key, somehow
<clever>
so if you get root via some means (like an exploit in the gui), you can read the key, read the firmware, patch it, re-sign, and re-flash
<clever>
for the rpi4, its using the exact same algo, but the "per-device" key is constant across all devices
<clever>
the rpi1-3 also supported hmac-sha1 signatures, but it wasnt enabled in the OTP
<clever>
so the mask rom didnt enforce it
<clever>
i have also written up detailed plans, on how to get proper secureboot on an rpi (any model)
<clever>
basically, you just need to get the factory assembling pi's, to not program the key in OTP
<clever>
then you need to get a bootcode.bin that can validate the signature on the next stage, all the way down the chain
<clever>
then sign things with your own key, and burn it into the OTP yourself
<clever>
the problem is mainly, getting bootcode.bin and start.elf to validate the next stages (lack of source, cant easily edit), and getting the factory to skip a step in production
* clever
heads to bed
vika_nez` has quit [Ping timeout: 264 seconds]
Darkmatter66 has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 265 seconds]
zupo_ has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ashkitten has quit [Quit: WeeChat 2.8]
ashkitten has joined #nixos-aarch64
zupo has joined #nixos-aarch64
pbb has quit [Ping timeout: 272 seconds]
pbb has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 256 seconds]
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
FRidh has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<evils>
what's up with flashrom on aarch64? (raspberry pi 3b+)
<sphalerite>
evils: I don't know, what is up with it?
<evils>
badPlatform
<evils>
error: #error PCI port I/O access is not supported on this architecture yet.
<evils>
srk: is that just an entry in config.txt? if it's more complicated than setting up rasbian, that may be the more effective path to get to my goal
<srk>
mount second partition and replace /mnt/boot/nixos/*-device-tree-overlays/ with these ^^
<srk>
btw which thinkpad?
<evils>
t410
<evils>
got support with the latest coreboot version, so obviously documentation on that is on point xD
<srk>
I have x200 flashed with libreboot and want to flash x230 but that one uses weird flash chips and I don't have a right clip
<evils>
solder wires to it?
<srk>
needs a bit of soldering, no time and will to do that as the fan is too noisy
<srk>
using passively cooled armv7 laptop instead :D
<evils>
so you mean mount the first partition of my pi's sd card?
<srk>
second. I could use some cores but would have to put it in the other room...
<evils>
or do you mean shut down my pi and plug the card into my workstation?
<srk>
hmm, doesn't matter
<evils>
srk: second is already mounted at /
<srk>
yeah, than try replacing the dts files if it's not read-only banned
<evils>
i don't know where i'd find those
<srk>
echo /boot/nixos/*-device-tree-overlays
<srk>
oh
<srk>
something similar
<evils>
ah, i'm only seeing /boot/nixos/*-dtbs
<srk>
that name is due to PR and using overlays on original dtbs
<srk>
right
<srk>
that is fine
<srk>
it is passed from /boot/extlinux/extlinux.conf
<srk>
via FTDIR directive
<srk>
*FDTDIR
<srk>
so you can also use my dir but change this var
<srk>
(either way works, kernel just needs to find the dtb for your device)
<evils>
ok, so edit extlinux.conf's latest entry to have FDTDIR point to your overlay?
<srk>
to the dir from extracted tar file
<srk>
resolution of specific dtb per board is done by kernel/uboot
<evils>
can i point FDTDIR to /home/evils/... or does it have to be in /boot?
<srk>
not sure, use /boot to be safe
<evils>
rebooting
<evils>
i maybe should have disconnected the SPI flash while doing that...
<evils>
so i skipped quite a bit of the stuff you said because i didn't understand it, i'm not seeing /dev/spi*
<srk>
are the modules loaded?
<srk>
check dmesg as well
<evils>
`dmesg | grep spi` just mentions loading the modules
<srk>
hm
<evils>
all i did was change the FDTDIR line, did i have to do any more configuration?
<srk>
not really
<evils>
any way to confirm it used the right overlay?
<srk>
yeah that's what I'm trying to remember :D
<srk>
it should BUG on spidev in dmesg
<srk>
with oops
<srk>
like the dtbs are built for 5.5 but I guess they should work with 5.6 as well
<srk>
I've only tested with pi2 I think
<srk>
could upload full image but it's 1.2G
<evils>
meh, i'm setting up rasbian atm
<srk>
yeah, there it's just a matter of putting corrent dt_overlay to config.txt but none of that is upstreamed which is why it so complicated the other way
samrose has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<evils>
srk: you're saying there's some setup there beyond loading modules as well?
<samueldr>
do understand it's not even close to being as close to being ready as other mobile devices
<sphalerite>
niiiiiice
<sphalerite>
stil
<samueldr>
and it requires a tethered exploit
<samueldr>
meaning no reboot
<sphalerite>
that's what we have kexec for, right? :p
<samueldr>
what about panics?
<gchristensen>
very cool
<samueldr>
it still annoys me to no end how rude it is to disallow running your own code
<sphalerite>
samueldr: kexec! :p
<sphalerite>
(crash kernel)
<samueldr>
it should be seen as a total disrespect of the user
<samueldr>
which makes it almost surprising how google of all the big names it the last bastion of doing it right :/
<gchristensen>
ooof yeah
<samueldr>
like *totally* right
<samueldr>
where you can enroll your own security keys, at the minimum
<samueldr>
and on some devices even change the whole dang firmware :|
<samueldr>
I have great hopes for the google SoC, hopefully the phones too will be safe to tinker with
<samueldr>
assuming it ends up existing, since every year google is "secretely" (not secretely) working on using their own chips according to... all blog postey outlets
<sphalerite>
samueldr: well, on chromebooks with the GSC you can't flash that…
<samueldr>
indeed, but you still control the *useful* parts of the boot process
<samueldr>
that chip is also open source, and IIRC inspectable from the running system
<samueldr>
such a component I even *expect* in a safely tinkerable device
<samueldr>
be it from the bootrom/maskrom of the CPU or as a more involved component
<samueldr>
when well-implemented, it brings both security *and* freedom-to-tinker to the user
<samueldr>
qualcomm would have a safe to tinker with system if the bootrom didn't check signatures... but that would obviate all security
<samueldr>
so it makes sense to have a well-identified component that takes on the role here
<samueldr>
it mediates between the user's freedom and security in an observable manner
<sphalerite>
hmmmm okay
<sphalerite>
thanks for the explanation :)
<samueldr>
not sure if you see what I mean?
<samueldr>
you have to decide where on the ladder of abstraction you make your concessions
<samueldr>
with apple's devices, you make it extremely high, where you're stuck on the userland with IIRC apple-provided signing
<samueldr>
with locked android devices, stuck on the userland, but with mostly free reign with all that's available there
<samueldr>
with unlocked android devices it varies, and security varies too
<samueldr>
with most laptops and such you are at ring 0, where you can change the operating system, but not the firmware
<samueldr>
where security varies too
<samueldr>
on chromeos-based devices you are safe and secure to tinker with at "ring -1"
<samueldr>
it could be made safe to tinker, but not secure to tinker with if it was made like e.g. the pinebook pro and other misc. aarch64 devices with an SPI flash
<samueldr>
where you can always use the insecure boot operation mode of the CPU to boot whatever
<samueldr>
(it's quite funny how I'm having a discussion with friends on the same topic in parallel)
<samueldr>
I think I want to think more about that, research the topic even more, and write a personal blog post about all that, since it's not an easy topic
<samueldr>
it's basicall two intertwined ladders
<samueldr>
a huge mistake with one and you can't stand on the other