GrapheneOS accessed Android security patches but not allowed to publish sources
grapheneos.social315 points by uneven9434 2 days ago
315 points by uneven9434 2 days ago
Related discussion earlier this week, https://news.ycombinator.com/item?id=45158523
So basically to summarize, Google embargoes security patches for four months so OEMs can push out updates more slowly. And if those patches were immediately added to an open source project like GrapheneOS, attackers would gain info on the vulnerabilities before OEMs provide updates (the GrapheneOS project can see the patches, but they can't ship them). But a lot of patches end up being leaked anyway, so the delay ends up being pointless.
The stupidest part is that, according to the thread, OEMs are allowed to provide binary only patches before the embargo ends, making the whole thing nonsensical since it's trivial to figure out the vulnerabilities from the binaries.
Fun fact: Google actually owns the most commonly used tool, BinDiff ;)
Unless the OEMs bundle numerous changes with the security patch(es).
(I'm not saying it happens. I just theorise how the policy could have been envisaged)
In the good old days, there were exploits patched years prior by some OEMs that were never upstreamed even to Google. New rooting apps come out and... just doesn't work. I don't know if that still happens, though.
Not really.. numerous changes are still not a total redesign of whichever subsystem was affected so it's pretty obvious where some small security relevant changes are. A stupid embargo was always enough to ruin security by code analysis for white hats but never enough to stop attacks by code analysis for black hats.
How does this work legally? If Android AOSP is open-source, once one OEM updates, surely the owner gets the legal right to request sources. IIRC the maximum delay is 30 days.
Almost all of AOSP is under the Apache or BSD licenses, not the GPL. Very few GPL components remain (the kernel being the large and obvious one).
So, yes, making a GPL request will work for the very few components still under GPL, if a vendor releases a binary patch. But for most things outside of the kernel, patch diffing comes back into play, just like on every closed-source OS.
weird tangential question then: when does GPL stop being infectious?
I would understand in a modular system like an operating system: one can argue that the kernel is a single component.
But if you're buying an appliance, the OS is effectively one single unit: all linked together.
Why does a binary executable and a binary image seem to operate differently in this space - both are inscrutable?
The FSF has always been pretty clear on this: you use a linker (static or dynamic) = it applies; you don't = it doesn't. They even wrote LGPL with this distinction in mind, and introduced exceptions to yacc (bison) to accommodate non-free software.
In case of binary releases, you can request the sources of the relevant subcomponent (e.g. the kernel). The component boundaries are pretty clear wrt Linux: Torvalds has made it quite clear early on, that the kernel's GPL2 does not apply to anything in the user space.
Here also, the important distinction between GPL 2 & 3: with GPL3, it would be a breach of the license to ship code on a device that does not allow the end user to update that code. Which has effectively pushed everyone away from GPL3-licensed software.
IMHO the move to GPL3 has likely caused more harm than good to the FOSS ecosystem; in some alternative universe, GPL3 never happened, most of Android's userspace is GPL2, and we get the source for everything. In both universes we still don't get to deploy changes to devices we own, so IMHO the GPL3 won us nothing.
The FSF considers linking to be a definite example of derived works in general, but I don't believe they consider lack of linking to prove that something isn't a derived work.
The goal of the GPL is to flip draconian copyright maximalism on its head, and copyright laws don't talk about linkers so that can't be the deciding factor. Not to mention that it would be trivial to work around linking by creating a stub and calling the GPL code as a subprogram (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).
> (in kernel contexts a spiritually similar setup is called the "GPL condom" and my impression is that most lawyers not employed by NVIDIA consider this to not be a get-out-of-jail-free card).
The whole thing with Linux's conception is that it's predicated on any and all unlicensed usage of GPL-only interfaces being copyright infringement of other usage in the kernel source. This is an extremely broad claim to make in general (especially in light of Google v. Oracle), and the 'GPL condom' approach is just to further ensure that the unlicensed side is textually unrelated to the kernel. When there's no infringement, the copyright holders can't do a single thing, except to technologically make it harder on you.
Meanwhile, the whole GPL idea of linking vs. statically embedding is only applicable when you're shipping someone else's GPL-licensed code alongside your non-licensed code, in which case you're bound by its terms. If you're not shipping someone else's code, then there's plenty of ways to force a particular build, etc., in the manner that the GPL is trying to prevent. Heaven knows I've likely violated the spirit of the GPL before just through Hyrum's law.
I see what you're getting at, but on the other hand there is also a difference between APIs that are intended for use by third parties that are just "regular usage of the program" and internal functions that are being exposed due to technical factors in how the source code is organised (i.e., the fact that Linux organises its code into loadable modules and does not expose all symbols to try to avoid needless breakages).
To be clear -- the general view is that the GPL is viral in both cases (in fact the general view is that any user of the published interfaces of a GPL-licensed library is a derived work -- even in cases not involving compilation or linking), but I think the kernel module case is even more clear-cut than that.
In my view, the fact that the Linux kernel interfaces change incredibly frequently in every release specifically in response to internal code changes really makes it hard to believe that usage out of tree is just the same as using the syscall interface (which is what NVIDIA et al. tend to argue). (Note that the Linux syscall exception is actually not the license for the entirety of Linux -- almost none of my code contributions have been under the syscall exception and the same is true for almost all Linux contributions.)
For what it's worth, I think the distinction between EXPORT_SYMBOL and EXPORT_SYMBOL_GPL has been a net harm to any discussion about module-related GPL violations, precisely because there isn't an obvious line you can draw between their usage and it just muddies the waters unnecessarily (recent attempts to further lock this down seem to indicate some kernel developers agree that this was a mistake). If you imagine an analogous case with a Python program and someone adding files to it which modify the internal state of the original program through interfaces that were only visible because of technical aspects of code organisation, the case becomes far more clear and I don't think further technical shenanigans solve the underlying legal issue.
Google v. Oracle was also about copying the interface itself and whether replicating said interface was fair use (which I think everyone except Oracle would find to obviously be true, otherwise the entire history of GNU and Linux would be one of copyright infringement). It was not at all concerned with creating combined works through the use of an interface. You could try to make the argument that (in light of Google v. Oracle) that the generally accepted view of users of a GPL-licensed library being derived works of said library is somewhat questionable, but I think that's a separate discussion (as I said, I think the module discussion is even more clear-cut).
If you write code simply using an interface, then it's nigh-impossible to infringe on someone else's code implementing that interface, regardless of how internal or technical or particular or unstable that interface is. The provider and consumer are simply doing two different things, and are expressing two different ideas, even if you look at it under the abstract lens of SSO.
Instead, they would have to argue that your code using the interface infringes on either (a) the interface itself, or (b) some of their other code using the interface. The former case (a) has been greatly weakened in light of Oracle v. Google (especially in the driver context where you can argue for interoperability), and my impression is that the latter case (b) can often be minimized to the point that it also falls under fair use. Alternatively, the 'GPL condom' separates the ultimate user even further from any copyrightable elements of the provider's code.
The provider of the interface could try to make it so fiddly that it can only be used in one specific copyrightable way, but if it's so bad that even using a 'GPL condom' would infringe, then you could plausibly spin something from Sega v. Accolade.
In other words, I think the "generally accepted view" you refer to is extremely questionable, even in the context of kernel modules. People just steer clear of these hairy questions out of an abundance of caution, especially when their actions wouldn't net them enough money to pay for litigation. (And as it happens, Nvidia is netting tons of money!) And with a well-designed 'GPL condom', it would be a very uphill battle for the provider to argue that the ultimate user has infringed on some copyrightable element of their code.