5 ms·

Reverse-Engineering the Mali G78

122 points by caution 5y ago

rektide 5y ago
such colossal public good. kind of weird to me that we still have so few phones that have started running mainline. there's a lot of postmarketOS phones, but my understanding is they Helium/libhybris which mixes in a ton of the Android support infrastructure/drivers to do the job. i could be overly concerned, but there being so few distributions & such specific distributions targeting phones is exactly the good this work OUGHT to be unlocking, & it just seems like progress in making that happen is disorganized / not really happening, alas alas alas. getting a toe-hold in, where we start to see self-determinism on what our devices run, would be such a compelling & powerful vision. i really hope we can start to see that! ubuntu touch targets the Pixel3. i'd be curious to know what they did. PinePhone & Purism really took it from the top, have their own hardware that starts in a more easy-to-work with set up. but I don't see why that would be required to get a decent regular linux distro (arch, debian) running on a phone, with a gui (sans many device drivers!).
- opan 5y ago
  Some of the better-supported pmOS devices are running mainline, such as the OnePlus 6.
  - rektide 5y ago
    right! thanks! i forgot about the oneplus6 & it's progress! figuring out how to get a kernel & normal environment booting seems to be one of the biggest challenges. there is a TianoCore EDK2 porting effort underway that seems to have support on a good number of phones. who knows what works & doesn't once you are able to start running your own mainline kernel, but way cool to see over a dozen phones on this list! genuinely excited to have some 3(+) year old phones (mostly now unsupported, insecure, or about to be!) to start to get to play with!! this could well be a flagship demonstration of what a Right to Repair can do: save a lot of devices the landfill, prove very enduringly useful to people, once they have some self-determinism with their purchases. ad astra emptor. https://github.com/edk2-porting/edk2-sdm845 https://github.com/edk2-porting/edk2-sdm845
    - floatboth 5y ago
      There's also https://www.somainline.org https://www.somainline.org focusing on SDM630/660, I'm pretty sure they have Freedreno working on these SoCs, unfortunately so far pmOS isn't adopting their latest kernel work all that quickly (?)
- ajklsdhfniuwehf 5y ago
  because when someone goes out of the way to give us a phone with mainline and a qwerty physical keyboard like we have been asking for ages, nobody buys and they go bankrupt? https://www.gsmarena.com/blackberry_key2-9187.php https://www.gsmarena.com/blackberry_key2-9187.php :)
  - ece 5y ago
    Essential did the same thing with the PH-1. I think Google has been trying, and with their own SoC, maybe they will finally be able to accomplish this goal.
  - bsder 5y ago
    A) Until your comment, I didn't even know this existed. That's a massive marketing failure. B) Most Chinese smartphones dump all over this with the exception of the keyboard--which comes in for all sorts of grief for being crap. You had one job Blackberry ...
  - GranPC 5y ago
    The Key2 does not run a mainline kernel, and the bootloader is locked down so you cannot run your own kernel or OS. This is not the phone "we have been asking for".
- ant6n 5y ago
  How would a Linux phone be wrt security? I just had my iphone stolen, don't have to worry too much about data loss because it's unlikely somebody will crack into it. I don't think that's true for Android, but I'm not sure about Linux phones.
  - codetrotter 5y ago
    A first step would be to do the same thing on your Linux phone as you'd do on a Linux desktop or laptop, encrypt the storage. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti... However, the difference of course is that with a desktop especially and also with a laptop if you are actually careful with the security of your data, is that you generally turn them off when you are not using them, so that they don't sit unprotected with the encryption keys in RAM, and they are unlikely to be stolen while you are using them. A phone, on the other hand, is probably turned on 24/7. But really, if someone is ready to extract the storage encryption keys of your phone from its RAM, those same people will probably snatch your laptop out of your hands while you are using it and it's unlocked. So as long as you are able to encrypt the storage of the phone with LUKS, I think you shall have nothing to worry about with most phone thieves. OTOH, having the storage completely unencrypted I think even the regular low-level criminals may decide to snoop on your data. At least if it's an SD card that you can just pop into a computer. But then again, neither Windows nor macOS read any of the common Linux filesystems out of the box. So probably even without encryption most thieves would not get to your data unless they were specifically motivated to go for it, and in which case as mentioned they might as well snatch your laptop (or your iPhone) from out of your hands when it's booted and unlocked.
    - awesomeusername 5y ago
      Also anyone compitent enough to do that likely has better options available than stealing phones
  - rektide 5y ago
    that would depend on what the practitioners imagine & build for themselves as ideal security regimes, wouldn't it? we can build exactly whatever we want! wanna run Tails on your phone? go for it. that should be secure.
- MayeulC 5y ago
  Last time I looked, few pmos devices used libhybris. They're mostly downstream kernels with no GPU acceleration, though they're getting progressively mainlined. Mainlined phones generally try to leverage OSS drivers where possible.
nicoburns 5y ago
I don't understand why ARM don't just release the source to their drivers. Seems like they'd have a lot to gain and little to lose bu doing so.
- ironman1478 5y ago
  I haven't worked with their GPUs but I do work with their camera ISPs. I suspect that their reason might be that that seeing how to write software against the chip sort of gives away the secret sauce for how the chip works. I don't know if I would agree with that, but you can kind of intuit the design of chip based on its interface. How much values that provides is unclear though :/. Also, they do charge customers for that code and it costs money to support/customize it work customer use cases. I suspect that's another part of the equation.
  - Nextgrid 5y ago
    I'd argue that anyone who has the skills & resources to make use of the "secret sauce" to compete wouldn't be stopped by having to reverse-engineer a binary driver?
    - ironman1478 5y ago
      You're probably right. But I'm just saying what ARM might be thinking.
- brandmeyer 5y ago
  AMD rationalized closed-source driver development as a defense against the release of hardware trade secrets.
  - flakiness 5y ago
    I thought they mostly open-sourced the GPU driver for Linux? I interpret it as a way to compete against(proprietary) CUDA dominance, but maybe that is wrong? https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/amd/amdgpu https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...
anonymousiam 5y ago
Over 30 years ago, I was doing some OS9 (Microware, not Apple) development on a 68k embedded target. I needed a PIO driver that could do bi-directional I/O. The OS came with a PIO driver, but it wouldn't let you switch directions. I approached the vendor with several options: 1) I will pay you to write another driver with this functionality. 2) License the driver source code to me and I will do it. For reasons I do not remember, they would not do either. I ended up reversing their PIO driver and implementing a version with the functionality I needed. I was uneasy about doing this, but we never sold or distributed the work so it was probably legal. (The development was for an in-house application with just one target.)
pabs3 5y ago
They probably could have avoided needing to cross-compile by using a chroot under Android. There are lots of tools, and also the manual way. https://wiki.debian.org/ChrootOnAndroid https://wiki.debian.org/ChrootOnAndroid
- the-dude 5y ago
  They were sure they could avoid using chroot by doing a cross-compile. I am pretty sure Collabora know what they are doing.
fulafel 5y ago
This was good for a chuckle: > On Android, we must cross-compile from a desktop with the Android Native Development Kit, ironically software that doesn’t run on Arm processors.
- defer 5y ago
  Heh, I do android platform development for a living. Most devices are obviously ARM but you can't compile android on arm processors.

122 points by caution 5y ago

such colossal public good. kind of weird to me that we still have so few phones that have started running mainline. there's a lot of postmarketOS phones, but my understanding is they Helium/libhybris which mixes in a ton of the Android support infrastructure/drivers to do the job. i could be overly concerned, but there being so few distributions & such specific distributions targeting phones is exactly the good this work OUGHT to be unlocking, & it just seems like progress in making that happen is disorganized / not really happening, alas alas alas. getting a toe-hold in, where we start to see self-determinism on what our devices run, would be such a compelling & powerful vision. i really hope we can start to see that! ubuntu touch targets the Pixel3. i'd be curious to know what they did. PinePhone & Purism really took it from the top, have their own hardware that starts in a more easy-to-work with set up. but I don't see why that would be required to get a decent regular linux distro (arch, debian) running on a phone, with a gui (sans many device drivers!).

opan 5y ago
Some of the better-supported pmOS devices are running mainline, such as the OnePlus 6.
- rektide 5y ago
  right! thanks! i forgot about the oneplus6 & it's progress! figuring out how to get a kernel & normal environment booting seems to be one of the biggest challenges. there is a TianoCore EDK2 porting effort underway that seems to have support on a good number of phones. who knows what works & doesn't once you are able to start running your own mainline kernel, but way cool to see over a dozen phones on this list! genuinely excited to have some 3(+) year old phones (mostly now unsupported, insecure, or about to be!) to start to get to play with!! this could well be a flagship demonstration of what a Right to Repair can do: save a lot of devices the landfill, prove very enduringly useful to people, once they have some self-determinism with their purchases. ad astra emptor. https://github.com/edk2-porting/edk2-sdm845 https://github.com/edk2-porting/edk2-sdm845
  - floatboth 5y ago
    There's also https://www.somainline.org https://www.somainline.org focusing on SDM630/660, I'm pretty sure they have Freedreno working on these SoCs, unfortunately so far pmOS isn't adopting their latest kernel work all that quickly (?)
ajklsdhfniuwehf 5y ago
because when someone goes out of the way to give us a phone with mainline and a qwerty physical keyboard like we have been asking for ages, nobody buys and they go bankrupt? https://www.gsmarena.com/blackberry_key2-9187.php https://www.gsmarena.com/blackberry_key2-9187.php :)
- ece 5y ago
  Essential did the same thing with the PH-1. I think Google has been trying, and with their own SoC, maybe they will finally be able to accomplish this goal.
- bsder 5y ago
  A) Until your comment, I didn't even know this existed. That's a massive marketing failure. B) Most Chinese smartphones dump all over this with the exception of the keyboard--which comes in for all sorts of grief for being crap. You had one job Blackberry ...
- GranPC 5y ago
  The Key2 does not run a mainline kernel, and the bootloader is locked down so you cannot run your own kernel or OS. This is not the phone "we have been asking for".
ant6n 5y ago
How would a Linux phone be wrt security? I just had my iphone stolen, don't have to worry too much about data loss because it's unlikely somebody will crack into it. I don't think that's true for Android, but I'm not sure about Linux phones.
- codetrotter 5y ago
  A first step would be to do the same thing on your Linux phone as you'd do on a Linux desktop or laptop, encrypt the storage. https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_enti... However, the difference of course is that with a desktop especially and also with a laptop if you are actually careful with the security of your data, is that you generally turn them off when you are not using them, so that they don't sit unprotected with the encryption keys in RAM, and they are unlikely to be stolen while you are using them. A phone, on the other hand, is probably turned on 24/7. But really, if someone is ready to extract the storage encryption keys of your phone from its RAM, those same people will probably snatch your laptop out of your hands while you are using it and it's unlocked. So as long as you are able to encrypt the storage of the phone with LUKS, I think you shall have nothing to worry about with most phone thieves. OTOH, having the storage completely unencrypted I think even the regular low-level criminals may decide to snoop on your data. At least if it's an SD card that you can just pop into a computer. But then again, neither Windows nor macOS read any of the common Linux filesystems out of the box. So probably even without encryption most thieves would not get to your data unless they were specifically motivated to go for it, and in which case as mentioned they might as well snatch your laptop (or your iPhone) from out of your hands when it's booted and unlocked.
  - awesomeusername 5y ago
    Also anyone compitent enough to do that likely has better options available than stealing phones
- rektide 5y ago
  that would depend on what the practitioners imagine & build for themselves as ideal security regimes, wouldn't it? we can build exactly whatever we want! wanna run Tails on your phone? go for it. that should be secure.
MayeulC 5y ago
Last time I looked, few pmos devices used libhybris. They're mostly downstream kernels with no GPU acceleration, though they're getting progressively mainlined. Mainlined phones generally try to leverage OSS drivers where possible.

nicoburns 5y ago

I don't understand why ARM don't just release the source to their drivers. Seems like they'd have a lot to gain and little to lose bu doing so.

ironman1478 5y ago
I haven't worked with their GPUs but I do work with their camera ISPs. I suspect that their reason might be that that seeing how to write software against the chip sort of gives away the secret sauce for how the chip works. I don't know if I would agree with that, but you can kind of intuit the design of chip based on its interface. How much values that provides is unclear though :/. Also, they do charge customers for that code and it costs money to support/customize it work customer use cases. I suspect that's another part of the equation.
- Nextgrid 5y ago
  I'd argue that anyone who has the skills & resources to make use of the "secret sauce" to compete wouldn't be stopped by having to reverse-engineer a binary driver?
  - ironman1478 5y ago
    You're probably right. But I'm just saying what ARM might be thinking.
brandmeyer 5y ago
AMD rationalized closed-source driver development as a defense against the release of hardware trade secrets.
- flakiness 5y ago
  I thought they mostly open-sourced the GPU driver for Linux? I interpret it as a way to compete against(proprietary) CUDA dominance, but maybe that is wrong? https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/amd/amdgpu https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...

anonymousiam 5y ago

Over 30 years ago, I was doing some OS9 (Microware, not Apple) development on a 68k embedded target. I needed a PIO driver that could do bi-directional I/O. The OS came with a PIO driver, but it wouldn't let you switch directions. I approached the vendor with several options: 1) I will pay you to write another driver with this functionality. 2) License the driver source code to me and I will do it. For reasons I do not remember, they would not do either. I ended up reversing their PIO driver and implementing a version with the functionality I needed. I was uneasy about doing this, but we never sold or distributed the work so it was probably legal. (The development was for an in-house application with just one target.)

pabs3 5y ago

They probably could have avoided needing to cross-compile by using a chroot under Android. There are lots of tools, and also the manual way. https://wiki.debian.org/ChrootOnAndroid https://wiki.debian.org/ChrootOnAndroid

the-dude 5y ago
They were sure they could avoid using chroot by doing a cross-compile. I am pretty sure Collabora know what they are doing.

fulafel 5y ago

This was good for a chuckle: > On Android, we must cross-compile from a desktop with the Android Native Development Kit, ironically software that doesn’t run on Arm processors.

defer 5y ago
Heh, I do android platform development for a living. Most devices are obviously ARM but you can't compile android on arm processors.