Reverse-Engineering the Mali G78 | Hacker News Reader

Reverse-Engineering the Mali G78

collabora.com

122 pointscaution30 comments

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.)

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!).

Some of the better-supported pmOS devices are running mainline, such as the OnePlus 6.

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

There's also 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 (?)

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

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.

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 ...

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".

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.

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_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.

Also anyone compitent enough to do that likely has better options available than stealing phones

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.

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.

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.

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.

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?

You're probably right. But I'm just saying what ARM might be thinking.

AMD rationalized closed-source driver development as a defense against the release of hardware trade secrets.

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/dr...

Yeah, and their main reason for some proprietary drivers existing is usually 3rd-party proprietary dependencies. E.g. they open sourced AMDVLK by starting with the closed Vulkan driver and replacing the proprietary compiler dependency with LLVM.

Much of the AGESA code for booting the system remains hidden.

Patents. Graphics and video are patent minefields.

If you don't officially release the documentation, opposing companies find it much harder to sue you for patent infringement.

Patents they have a license to use, but not to share, or fear of infringing some unknown patent, so they don't want to say much.

Transparency and openness are things that in-house lawyers probably attack by default. They point all imagined risks re patents and bugs, liability, reputation, and security, and they specialize in CYA arguments.

Not all lawyers are the same :). Sure, not releasing the source code exposes you to less risks. I think the main thing that these Chinese companies fear is that a competitor can produce similar products more easily if they have access to driver source code.

From a legal standpoint, I imagine you would have less liability for bugs, because you opensourced it for anyone to see and have the option to improve upon. If the company did not introduce the bugs on purpose or as a result of some really negligent behaviour, the company doesn't have to fear liability issues. Potential patent claims etc. may be filed, but you can assess that risk. Let a patent research firm do a risk assessment and tell you how much chance people would have suing you.

And all firms need to have some sort of legal liability insurance. If you can work it out with your insurance provider that you are going to opensource part of your code, you do not have to fear anything.

You could always release two different drivers, one basic opensource driver for the community. One closed source optimized driver for the company. If you are using some risky IP etc. keep it in the closed source driver.

AMD and Nvidia do this, seems to work for them.

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.

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

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

They were sure they could avoid using chroot by doing a cross-compile.

I am pretty sure Collabora know what they are doing.

Reply on news.ycombinator.com