• Development
  • General info for unsupported platforms (pure DIY, no official platform support)?

Looking before I leap into a potentially bottom-less rabbit hole. I can't be the first one to contemplate an attempt to get Graphene working on non-pixel devices, especially cheap knockoffs from various sources.

So, I have tons of questions, but I'll attempt to keep this simple. I have extensively messed around with x86/64 bootloaders and efi whatnot, even modified and built my own GRUB, but I have not dealt with android/ARM platforms at that level before, so not sure how initial boot works in this case, especially secure boot related bits and pieces. A very long time ago I wrote a couple non-linux drivers for a mobile platform, so working at this level is not completely foreign to me (but almost, to be honest).

Q's:

  1. What do you consider the top big-picture problems when contemplating bring up a platform?
  2. Rough idea of typical workflow Graphene devs use while bringing up new supported platforms?
  3. How high is the chance of bricking my physical dev device? Outside of disposable wifi routers, I have not mucked around with brick-able low level bits of embedded OSs, so don't know how reliably anti-brick the process is.
  4. Any rough idea on what types of devices (drivers) are "likely" supported out-of-the-box with stock Graphene, aka at least enough to get a booted and usable state, versus known "likely" problematic devices?
  5. Any specific reasons I should not pick up a cheap (but top-end "claimed" spec) android device off aliexpress to use as a personal play/development device and/or potential target platform?

"RTFM" is a totally acceptable response, but I'm asking now before digging in too much since I'm making a purchase decision on device now due to long lead time, and I learn new stuff better when I'm actually digging in and running stuff on-device, which is kinda important for new platform Im assuming. If there are notable projects already doing this, link would be great.

Thanks! Been periodically considering Graphene for many years, finally jumping in (head first?!?).

    pipe2null it may be worth looking more into why pixel is the only option offered. even if you were able to port a version to another device (highly unlikely), many of the benefits of Graphene would be compromised. there should be a link on the website, and a quick search of the forum will find discussion of this topic ad nauseum.

      pipe2null If you are thinking of porting GrapheneOS and you don't yet have it on a device, probably start by doing that. Arguably the next thing would be to solve something on the open-issues list. In terms of a GrapheneOS development device, Pixel 6a's are pretty cheap these days and still have lots of lifetime.

      If your focus is more on porting than on GrapheneOS, maybe look into DivestOS? Again I think adding a feature to an existing platform would be a good way to get started.

        de0u Arguably the next thing would be to solve something on the open-issues list

        Good advice, I'll look into that once I have device(s).

        itsjpb even if you were able to port a version to another device (highly unlikely), many of the benefits of Graphene would be compromised.

        Yes, indeed. That is part of what I'm trying to wrap my head around.

        Thanks for the input.

        Generally:
        I looked at GOS back in the day around the time of the rebranding from previous project names, and decided I wanted to try it out sometime, but didn't get around to it for all the normal reasons. Looking into it again recently, GOS is still the only distro that I have heard of that comes anywhere near what I want for personal (EVERYone should have) use, and if Im going to consider investing the massive amount of time it takes to fully dig into a platform for possible development, well, yea, GOS is probably the right choice as far as I am aware. If I have the wrong impression, please correct.

        Prior to posting, I went through FAQ, build instructions, and cursory forum search. Obviously, 99% of people are not looking for info regarding DIY bringing up currently unsupported devices. The FAQ is one the the most in-depth and well made FAQs I have come across in many years, but for a general audience it would be a gross waste of developer time to itemize all the "Why's" and "Why Not's" that have accumulated over many years.

        I have no doubt that the Pixel is an excellent selection as the vetted standard platform of choice, but "Why" is left more or less vague, and frankly the detailed justifications that I'm sure exist are not useful for me until after I get more relevant info jammed into my head, but if there exists a list somewhere it would make a great starter list on what I need to ramp up on prior to any significant time investment. The "Why Not" other non-Pixel platforms is mostly attributed to limited dev resources, strong desire to have a fully feature complete platform only lacking in open issues, and ultimately only really supporting one tightknit group of devices long-term and leaving the massive variety of other devices to be supported by other projects/OEMs forked from GOS. At least without major donations plus major increases in developers/time. My impression, at least.

        At the moment, I am mostly interested in the "Why Not's" from the perspective of a purely DIY attempted build/port of GOS (or whatever the best relevant distro is) for a cheap but "claimed" beefy aliexpress phone.

        A good example for the sake of discussion would be the aliexpress S23 16GB+1TB cheapie, assuming the bootloader can be unlocked and the advertised specs are not total BS. The GOS FAQ/build instructions give the impression that some drivers should work out of the box, but some drivers will be sketchy, and the overall sketchiness is also sketchy... I assume that a cheapie phone off aliexpress like the S23 would be loaded with malware, but I also assume most malware will get wiped by installing GOS. I do not like making assumptions, but that's all I got ATM.

        For personal use, I'll probably end up with the cheapest GOS officially supported pixel in decent condition I can find, but for a development device to learn the low level bits and pieces while (hopefully) bringing up a new platform... Well, something like the S23 is cheap enough that its not tooooo painful if I brick it, but the "claimed" specs also merit the effort to get GOS working on it (compared to extensive work to get a low-spec or older device working).

        To summarize as simply as possible:
        For a purely DIY development effort with no official GOS support, would targeting a cheap but newish beefy device (the aliexpress S23 as example) be a complete waste of time/money due to impossibility or extreme infeasibility, or is there a reasonable chance the device running GOS could be made at least "usable" without years of development effort. "Usable" for this context is: not intended for public release, booting with at least minimal set of working-ish drivers, working UI, at least basic network connectivity plus 4G/5G as nice-to-have, and privacy/security at least on par with typical off-the-shelf non-GOS mobile devices. What Nth degree of in/sanity is this?

        Thanks for all the feedback

          pipe2null

          What do you consider the top big-picture problems when contemplating bring up a platform?

          Only Pixels have AOSP support, you will have to create device trees and integrate any non-AOSP components from SoC vendors etc yourself. Oh and there's basically scarce to no documentation for most of AOSP.

          Rough idea of typical workflow Graphene devs use while bringing up new supported platforms?

          It's not comparable to what you want to do as Pixels have AOSP support.

          How high is the chance of bricking my physical dev device? Outside of disposable wifi routers, I have not mucked around with brick-able low level bits of embedded OSs, so don't know how reliably anti-brick the process is.

          Once you have things wired up, quite hard, nearing impossible.

          Any rough idea on what types of devices (drivers) are "likely" supported out-of-the-box with stock Graphene, aka at least enough to get a booted and usable state, versus known "likely" problematic devices?

          This isn't really the right question. GrapheneOS relies on AOSP's device support, which is only Pixels.

          Any specific reasons I should not pick up a cheap (but top-end "claimed" spec) android device off aliexpress to use as a personal play/development device and/or potential target platform?

          Nothing aside from Pixels really has the care and effort placed into implementing hardware security features whilst offering full, properly implementing support for an alternate OS. You can't have a reasonably secure OS on a device where the hardware is architecturally insecure and lacking several critical hardware security features.

          TLDR from me: Buy a Pixel.

            pipe2null At the moment, I am mostly interested in the "Why Not's" from the perspective of a purely DIY attempted build/port of GOS (or whatever the best relevant distro is) for a cheap but "claimed" beefy aliexpress phone.

            GrapheneOS is focused on security and privacy. Right now the set of devices that can run a third-party Android OS including strong security is: some Pixel 4s, Pixel 5s, Pixel 6s, Pixel 7s, the Pixel tablet, Pixel Fold, end of list. Other phones do not have verified boot for third-party OSs. It would be great if other devices did, but they don't.

            There are other issues, including the secure element.

            iPhone hardware is pretty secure, but iPhone hardware is not a plausible platform for GrapheneOS because Apple utterly rejects the notion of securely booting anything but iOS. There are lots and lots and lots of devices that will let you boot some kind of Android, but they do not provide security environments consistent with GrapheneOS. At present the intersection of good hardware security and third-party OSs is, unfortunately, just Pixel devices.

            Again, if you want to work on GrapheneOS I suggest you plan to do that work on Pixel devices (for the near term). If you want to work on porting Android in a general sense, another platform, perhaps DivestOS, might make sense.

            Porting GrapheneOS to an arbitrary insecure piece of Android hardware would result in something that absolutely wouldn't be GrapheneOS, sort of like porting a bicycle to skis.

            Please note that I do not speak for the GrapheneOS project.

              pipe2null Sounds like you want to dive into a new project, and ask for excuses to do it. I'd say just jump into it if that is what you are burning for these days. And buy a cheap Pixel with GOS for reference (and daily driver).

              If you dive deep enough you will become of value to others aswell. Burning interest and persistence will get you far in the long run.

                de0u ther phones do not have verified boot for third-party OSs.

                Yet DivestOS, that you mentioned earlier, has other hardware that support relocking.

                And even if that particular feature wasn't available elsewhere, security is always a balance. It'd be more useful to know what features could be available on what hardware, and how they would affect security, then to discount them entirely. I mean, you probably wouldn't suggest a phone put out by North Korea just because it appears to check the right boxes.

                flawedworld Nothing aside from Pixels really has the care and effort placed into implementing hardware security features whilst offering full, properly implementing support for an alternate OS. You can't have a reasonably secure OS on a device where the hardware is architecturally insecure and lacking several critical hardware security features

                The question though is what features? and what part of the thread model to they affect?

                Buying a pixel also negatively affects my security as I'd be giving money to a company actively spending oodles on tracking me and pushing user-hostile projects like Web Integrity API. Maybe there's other hardware missing some lower-risk protection that better fits my risk assessment.

                I walked a similar path to OP. I also looked at the FAQ, read it's rather vague list of device requirements, and had questions. I was hopeful that others had at least a start on what hardware supports what features, or even on how to determine if particular hardware supports required features.

                For me the learning curve to help in determining these things seemed too steep, and the community generally seemed happy to pay for pixels, so I moved on. I'll be happy to see whatever info you collect though @pipe2null.

                  • [deleted]

                  kenmacd Buying a pixel also negatively affects my security as I'd be giving money to a company actively spending oodles on tracking me and pushing user-hostile projects like Web Integrity API. Maybe there's other hardware missing some lower-risk protection that better fits my risk assessment.

                  There's absolutely nothing Google-related on a Pixel running GrapheneOS.

                    [deleted] I think you might mean that it doesn't ship with Google services by default, which is true, but really, AOSP itself is essentially Google code, if we want to get pedantic about it. :)

                      The below recent event is what prompted me to get off backside and finally install GOS or whatever the best mobile distro is for privacy/security that results in a device that is still usable for more than a walkie-talkie. Keep in mind that I have my own personal ISP and mobile service, all from different providers than all other household members, traffic is strictly segregated, and I have zero tolerance that noone but myself ever touches any of my devices.

                      A couple weeks ago a family member had an old friend over that happens to be a retired pastor, and they of course discussed religious things during their visit, talking in front of that family member's alexa and/or other devices. I am not personally religious and there should be no leaked information online that would attribute "religious" to any of my accounts. Now I have religious content popping up as suggestions on youtube, as well as content suggestions similar to other household members interests that have nothing to do with any of my own trackable web surfing/etc. And this kindof thing happens waaay too much even with the digital separation from the rest of the house, and that is just based on information that has presented visible signs of information being used in ways I don't want, and says nothing about information used behind the scenes that I am 100% unaware of. Tip of iceberg. There are a million ways data could have been crossreferenced in grossly undesireable ways, but, yea.

                      The point is that even if I have absolute perfect security (does not exist) for my own devices and accounts, I and everyone else is still victim to every other person's devices, your neighbor's and public and privately located IoT, bluetooth tracking, etc etc etc. None of these ubiquitous problems are going to get solved in any satisfactory way, but it would be really really really good if personal security tech like GOS was much more easily accessible, adoptable, and (hopefully sooner than later) OEM supported in a meaningful way. Every convert is one less device spying on you AND everyone around you.

                      Which brings us to my OP. If a fork of GOS was able to reasonably support one or more cheap aliexpress devices, then a small company or even just a single dev could import for cheap, install psuedo-GOS, mark up the price to cover the work plus basic tech support, and still sell it at a pricepoint that is competitive enough for people to take a chance on a no-name company/person selling devices running a virtually unknown-to-normal-folk niche OS. Get enough adopters (no technical ability needed to click "buy") and real OEMs might get interested enough to take it mainstream. I am not personally trying to start a company, I just don't see another way to worry a little less about OTHER people's devices.

                      So, that is where I am coming from for this thread. Honestly, I am not really itching for a new major project since I have tons of small projects kicking around here and there. But at the moment I am still pretty pissed off from my recent reminder on how bad data collection is. Always known it, but it's convenient to insert head into sand or the age-old BS of "assess your threat model" which NEVER takes into consideration OTHER people's threat models. Still trying to separate out my actual interest in the extreme dev project of bringing up a new device, and just being pissed off and disgusted.

                      kenmacd the community generally seemed happy to pay for pixels

                      That's part of why I'm wondering about the cheap aliexpress phones. Bran new top end ones are on par or cheaper than a used pixel 6A, and a fraction of the price of a 7. The temptation is significant, but they could be straight out of North Korea. Hah. Theoretically replacing OS would wipe most/all malware, but would still have all the other big problems of an unsupported platform. The jury for purchase decision not sure.

                      dgzeij And buy a cheap Pixel with GOS for reference (and daily driver).

                      If you dive deep enough you will become of value to others aswell.

                      Yea, that is what I've been thinking, and it's also why I started looking at alternate platforms as it is something with basically zero support, thus even token contribution is infinite. Hah!

                      flawedworld Only Pixels have AOSP support, you will have to create device trees and integrate any non-AOSP components from SoC vendors etc yourself. Oh and there's basically scarce to no documentation for most of AOSP.

                      This is the kind of big picture issue I was wondering about. Thanks!

                      de0u Other phones do not have verified boot for third-party OSs.

                      Another important big picture issue. Is it reasonable to equate "verified boot" with x86/64 efi secure boot, or is that a gross mischaracterization? Certs exist in mobo firmware, firmware checks efi executable's signatures prior to executing, signed executables are required to check signatures for any chainloaded execs/kernels, etc?

                      So:
                      I will be buying a pixel for daily driver as soon as I find a listing worth gambling on. Not sure what hardware I will end up trying for purely dev purposes.

                      Many thanks for all the great feedback, and hope the discussion progresses.

                        kenmacd Yet DivestOS, that you mentioned earlier, has other hardware that support relocking.

                        Relocking is not the same thing as verified boot. If you have a locked bootloader, but the OS is exploitable in a persistent way, and you don't have verified boot, then persistent malware can persist without detection.

                        I looked at this DivestOS "Verified Boot Hashes" page. Some of the devices are listed as "End of Life", meaning that the firmware underlying the OS is unsupported and thus, over time, more likely exploitable. Some of the devices (e.g., "hotdog"), are marked as having Verified Boot but also as "Relockable: No". That combination may mean that you'd need to check the boot hash on every boot, and also that if somebody had your device for a while they could install an exploit, exfiltrate data, and then reinstall.

                        By no means am I trying to be negative about the DivestOS project. The question was about why the GrapheneOS team isn't targeting a wider variety of devices. As far as I can tell, the difference between the devices the GrapheneOS team is supporting and other presently available devices they are not supporting is clear and significant.

                        Here is the official statement on "Which devices will be supported in the future?". Here is my attempt at a summary:

                        • possible to install third-party OS (I read this as including lockable bootloader)
                        • hardware keystore
                        • verified boot & attestation
                        • hardware exploit mitigations (I read this as including hardware keystore throttling among other things)
                        • IOMMU isolation of co-processors
                        • ongoing support for firmware (including security updates)
                        • ongoing support for device drivers (including security updates)

                        Those features add resistance to genuine classes of attack. Leaving some of them out reduces the resistance of a platform to local and/or remote attacks. These are all things that non-Google hardware vendors could do, and arguably should do. However, some are expensive, and some would probably cut down on platform revenue (e.g., allowing a third-party OS is likely to reduce revenue from a company's app store).

                        As long as only Pixels support just these four items:

                        • installing a non-vendor OS
                        • re-locking the bootloader
                        • verified boot
                        • security patches to firmware and drivers

                        ...I won't be surprised if the GrapheneOS team sticks to just Pixel devices. If there are devices that do those, then it might make sense to argue about whether or not IOMMUs are important (I think so), whether a tamper-resistant key store with hardware throttling is important (I think so), whether MAC randomization in Wi-Fi scanning is important (I think so), etc. But it seems as if core things are missing from everything except Pixels at present.

                        These are just my personal opinions. I don't speak for the GrapheneOS project.

                          pipe2null [Brand new top end cheap aliexpress phones] are on par or cheaper than a used pixel 6A, and a fraction of the price of a 7. The temptation is significant, but they could be straight out of North Korea. Hah. Theoretically replacing OS would wipe most/all malware, but would still have all the other big problems of an unsupported platform.

                          What firmware will drive the Wi-Fi/Bluetooth chip? What if that firmware has a remote-exploit bug (like this 2017 bug or this 2019 bug)? How about this 2023 over-the-Internet exploit for Samsung Exynos modem firmware?

                          "Wiping the OS" while retaining the vendor's baseband firmware, Wi-Fi/Bluetooth firmware, GPU firmware, etc., means living with a huge body of code where you don't have the source and binary patching would be quite difficult. Coming up with your own baseband firmware, Wi-Fi/Bluetooth firmware, GPU firmware, etc., is genuinely not easy.

                            de0u
                            No real argument there. Part of the point of starting this thread was to get an idea of what hardware would probably work no problem, what probably wouldn't, and what might be flat out impossible. Many, many years ago, I was a developer on a small team bringing up/porting over an old smart phone platform to be used internally for development. Even with all the original source code from the OEM, it was still a PITA to get ported over, and having to deal with all the hardware problems the OEM just duct taped in their code. So I have a rough idea of what that type of work USED to be like back in the day, but things have changed very significantly since then both in hardware/OSs but also in the massive amount of open source hardware support (at least for SOME things).

                            To be very, very clear, this thread was intended NOT as request for GOS to support other platforms, but to be about general info for anyone considering an attempt at building up/porting over a new platform based on GOS or similar privacy/security oriented distro that would be used on a non-pixel device. GOS devs made it pretty clear in the FAQ and other places that it will not be them and they've presented very good and compelling reasons for that, and I fully agree and support them.

                            I just spent $350 on a used pixel 7A that only has 128GB of storage with no sdcard slot. It wont arrive for a few days, but I already feel ripped off due to lack of storage alone. So, yes, there are very good reasons why GOS will only support pixel, but there are many good reasons to consider other platforms as well.

                            pipe2null A couple weeks ago a family member had an old friend over that happens to be a retired pastor, and they of course discussed religious things during their visit, talking in front of that family member's alexa and/or other devices. I am not personally religious and there should be no leaked information online that would attribute "religious" to any of my accounts. Now I have religious content popping up as suggestions on youtube, as well as content suggestions similar to other household members interests that have nothing to do with any of my own trackable web surfing/etc.

                            What I don't understand is how the Big Tech could relate that conversation your physical self had at the pastor's and your digital identity. Do you have any clue about that ?

                              de0u Relocking is not the same thing as verified boot. If you have a locked bootloader, but the OS is exploitable in a persistent way, and you don't have verified boot, then persistent malware can persist without detection.

                              Thanks for the reply, and I think I get where you're coming from here.

                              I do get that depending on designs of coprocessors/shared buses, closed-source firmware, cpu core boot order, etc, that there's still risks there. I just wish they were enumerated on a 'potential device' list somewhere. I also completely get that GOS doesn't have infinite resources and has to make decisions to support what they can to do the most good.

                              I hope you can also appreciate that some might view the privacy risk of an over-the-air firmware exploit being burned on exploiting their device as lower risk than the funding an actively privacy-hostile company.

                              I guess my main point is this: there's a lot of people today running stock/roms/lineageos that don't get the benefits of any of the great feature list. It would be nice if they could get some protection rather than none.

                              • de0u replied to this.

                                Eirikr70 Do you have any clue about that ?

                                Pure speculation:
                                I may have completely separate accounts, but I still have the same delivery address as other Amazon users in the house including the owners of alexa/Iot/etc. Amazon has had deals with Google for a while to get amazon-related search results elevated, but no idea on quid-pro-quo of information sharing. Without analyzing the exact info Alexa/etc is sending back, it is unclear how much Alexa/etc actively identifies individual people within its range via bluetooth devices in pockets or plain old voice print whether or not the speaking person is directing those words at alexa (it hears all sound waves, not just intentional ones). It doesn't have to be very accurate when it can get continuous samples all day every day. I may not have been part of any religious conversation, but I am associated to the household. I once read that some smart tv remote controls have sensors built in to determine when different people are holding/using the remote (thus the one choosing TV programming), not to mention smart tvs themselves containing microphones and reports of actual camera sensors which ended up as part of an FBI cybersecurity warning notice. I read that FBI notice direct from FBI website, it is a real thing. The list goes on and on.

                                Once enough data is accumulated about a person, then filling in the gaps with indirect information is trivial.

                                Alternate explanation:
                                Big Data is so bad that it is easy to attribute sinister activity to what may be pure coincidence.
                                Or clicking on a video for an unrelated subject prompted the youtube algorithm suggestion religious content. I once clicked on an AR15 related video to see what all the hubbub was about, and to this day, like years later, I am inundated with ads for concealed gun holsters and ridiculous personal defense training courses for doomsday-ers.

                                kenmacd I do get that depending on designs of coprocessors/shared buses, closed-source firmware, cpu core boot order, etc, that there's still risks there. I just wish they were enumerated on a 'potential device' list somewhere.

                                That would be interesting. I think various wiki engines allow cooperative editing of tabular data (though perhaps not with the convenience of a Google Sheet). It would be necessary to exert some control/oversight to avoid spammers and vandals. But overall I think it would be interesting to have a database of security properties of various phone/tablet devices.

                                kenmacd I hope you can also appreciate that some might view the privacy risk of an over-the-air firmware exploit being burned on exploiting their device as lower risk than the funding an actively privacy-hostile company.

                                I do understand, and I genuinely think it would be great if there were more phone vendors shipping devices with reasonable security. I believe around a year ago the GrapheneOS developers were negotiating with a small phone company, but the negotiations fell through. Of course, it's important to keep in mind that Google isn't the only phone manufacturer that privacy-conscious people are concerned about (2016 2023). Maybe having a public database of devices and security issues might help companies decide to improve their devices.

                                I guess my main point is this: there's a lot of people today running stock/roms/lineageos that don't get the benefits of any of the great feature list. It would be nice if they could get some protection rather than none.

                                Which features? My sense (I am not an expert on this) is that the DivestOS project is doing their best, and doing reasonably well, at shipping as much security as can be shipped on the wide variety of devices they are supporting. I don't think there would be any licensing impediment if they wanted to adopt, for example, contact scopes from GrapheneOS.

                                kenmacd Hardware security features and proper SoC configuration are critical to having a secure platform.

                                A few notable things Pixels get right and have:

                                • Proper non-broken configuration of IOMMUs
                                • Non-broken AVB 2.0 (Android Verified Boot) support, with non-broken support for user defined root of trust (critical for running your own OS)
                                • A dedicated hardware secure element (In newer Pixels, this is the Titan M2) which provides..
                                  -- The Weaver API, without this the device encryption sucks pretty much, it provides brute force resistance
                                  -- Hardware KeyStore support - allows for storing secrets in secure element
                                • Modern TEE implementation running Trusty, which assists in brute force resistance
                                • Full AOSP support with device trees, drivers, HALs etc all ready to build (Just need to use adevtool to pull extra bits from stock OS images)
                                • Consistent security patches monthly
                                • Easily obtainable OTA and factory images for extracting files from
                                • More complete patching - Pixels ship a lot more than the baseline mandatory patches in Android Security Bulletins each month

                                That's a non-exhaustive list, which to-date, I have not found another device meeting these requirements. Just because a device looks like it supports a feature, for example a user defined root of trust for verified boot, does NOT mean it does it properly - for example, several OnePlus devices do not implement this properly at all. Hell, look at FairPhone, they can't even sign their OS with signing keys which are not the public test AOSP signing keys. Most of the industry is a damn shitshow. Having proper verified boot is a very important part of the Android security model.