5 ms·

This sounds extreme at first but if you had to support 15 years of security updates, how would you do it? What is the necessary human resources and structure to

by mrtksn 5y ago

This sounds extreme at first but if you had to support 15 years of security updates, how would you do it? What is the necessary human resources and structure to pull this off?

jewel 5y ago
I've got a laptop from 2004 that still works fine. It has 1.5 GB of RAM and a spinning 60GB hard drive. It runs the latest Xubuntu, which is getting security updates. Android should take a similar path. Mainline the kernel drivers, keep the minimum system requirements low (which you'll want to do anyway for 3rd world handsets), add developer modes to test apps with constrained RAM and throttled CPU, rank "eco-friendly" apps that have lower storage requirements higher on the play store. As far as the human resources required, see Ubuntu or Redhat Enterprise, which manage to do ten year support cycles for servers. I think handsets could be easier if you keep upgrading the kernel and core components instead of only applying security updates to the existing software. If you can do that then there's no more security work than you would otherwise be doing, since your latest handsets would need those security updates too.
StillBored 5y ago
Abstract the hardware platform from the OS and applications. You know, like pretty much every operating system except linux on arm. Everyone complains about having to install drivers on windows, but having a driver ABI is largely how one can expect 10+ years of OS updates without any particular engineering work. The OS and applications get updated and as long as they maintain the driver API the graphics drivers, network drivers, etc all continue to work. Once in a while you have to go back and revisit this stuff, but drivers themselves are rarely sources of exploits because they exist below all the userspace interaction shielded by the kernel, and on the HW side tend to be little more than shims to forward data/packets/etc from the HW to the OS.
- kllrnohj 5y ago
  > You know, like pretty much every operating system except linux on arm. Android is Linux on ARM but it also abstracts the hardware platform from the OS & apps, that's the whole "Project Treble" thing Google was talking about a few years back. https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html https://android-developers.googleblog.com/2017/05/here-comes... But that's the easy non-answer. Abstractions can't add features. Like Windows 11 dropped support for old hardware not because the right abstractions weren't in place, but because you can't add things like a TPM in software. It needs full stack support. Similarly if it turns out a device driver had a bug in its implementation of the interface, you're kinda stuck with that. And the workaround may or may not be reasonable to put up with, if a workaround exists at all.
  - StillBored 5y ago
    One doesn't need new features to "support" and older platform. You simply assure that code paths have fall back logic to deal with missing GPU functionality/etc and as you mention emulate it. The fact that this has worked for decades on lots of other OS's is proof of this. Iphone6's don't have facial recognition cameras but you can still unlock your phone/etc. Oh, and btw there are soft TPMs, which are the defaults on most new machines, and is probably part of the reason MS made it a requirement. But as others have shown by getting win11 to run without a TPM, it is entirely artificial, like when they decide not to ship IE/directX/whatever on an older OS. If a random hacker type can get it to work in a reasonable timeframe, there isn't really an excuse for MS not to just add the functionality with a little "your machine doesn't have a TPM so your not secure as you could be" notice somewhere. Its mostly laziness and market segmentation.
    - kllrnohj 5y ago
      That missing feature set bleeds into the developer experience and results in cries of "fragmentation." It's not "laziness" it has a real cost to 3p developers. And no, your claims of "just emulate it" is not accurate, nor is that how any other OS works. If you're missing a GPU feature on your Linux system (or, more likely, if your driver is even if your hardware supports it) it's up to everything that uses the GPU to not hit that path. Nothing is emulating it or in any way pretending to have a feature it doesn't "natively" have.
      - StillBored 5y ago
        Well of course, for somethings it becomes a least common denominator, but even for GPU's in the past the idea was that it was possible to use something like Mesa as the baseline and then accelerate the important/critical functionality in hardware. The original DX API was also designed like this. Its only once the market became basically a duopoly that the expectations shifted. Frankly, having a solid software reference model/fallback path likely makes peoples jobs easier because its easier to track down bugs by doing a/b testing. Oh, and BTW, you can likely boot your linux machine without your graphics card driver, and it will still be able to run your desktop/etc and simple openGL/etc applications like glxgears. How is that, because linux can and does fallback to software emulation, using... mesa.
jjulius 5y ago
Cool it on the whole "everyone needs a new phone every couple of years" thing, maybe? That's not the solution in and of itself, but it'd sure help. Not only would there be fewer variables in the hardware you have to support, but you help reduce e-waste.
- dymk 5y ago
  There's a big difference between 15 years and "couple of years", and on top of that, phones are particularly recyclable (and a good value to recycle, too! plenty of valuable metals in there).
yjftsjthsd-h 5y ago
Aggressive upstreaming and commoditization, mostly. When you build a device, you build it out of existing components where possible, and where it isn't you write drivers and immediately push to get them pulled up to the upstream Linux tree. You ship devices that always run run mainline kernels and little-to-no divergence from AOSP, that share as much code as possible (hence reusing components -> reusing drivers), you maintain a single ROM image with only the smallest changes per-device that you can possibly manage. And you staff a team that can maintain your software, but since you're sharing everything across devices - and with other vendors, since your drivers are tiny compared to the whole kernel+AOSP - you can maintain dozens of devices with only a little more effort than one or two. Oh, and I'd actually be on board with some sort of paid update program and/or crowdfunding after some point. Say 5 years of bug and security patches included in the price of the phone, and after that a small monthly fee that you use to keep up with the marginal cost of maintaining that device's unique drivers and code.

by mrtksn 5y ago

This sounds extreme at first but if you had to support 15 years of security updates, how would you do it? What is the necessary human resources and structure to pull this off?

jewel 5y ago

I've got a laptop from 2004 that still works fine. It has 1.5 GB of RAM and a spinning 60GB hard drive. It runs the latest Xubuntu, which is getting security updates. Android should take a similar path. Mainline the kernel drivers, keep the minimum system requirements low (which you'll want to do anyway for 3rd world handsets), add developer modes to test apps with constrained RAM and throttled CPU, rank "eco-friendly" apps that have lower storage requirements higher on the play store. As far as the human resources required, see Ubuntu or Redhat Enterprise, which manage to do ten year support cycles for servers. I think handsets could be easier if you keep upgrading the kernel and core components instead of only applying security updates to the existing software. If you can do that then there's no more security work than you would otherwise be doing, since your latest handsets would need those security updates too.

StillBored 5y ago

Abstract the hardware platform from the OS and applications. You know, like pretty much every operating system except linux on arm. Everyone complains about having to install drivers on windows, but having a driver ABI is largely how one can expect 10+ years of OS updates without any particular engineering work. The OS and applications get updated and as long as they maintain the driver API the graphics drivers, network drivers, etc all continue to work. Once in a while you have to go back and revisit this stuff, but drivers themselves are rarely sources of exploits because they exist below all the userspace interaction shielded by the kernel, and on the HW side tend to be little more than shims to forward data/packets/etc from the HW to the OS.

kllrnohj 5y ago
> You know, like pretty much every operating system except linux on arm. Android is Linux on ARM but it also abstracts the hardware platform from the OS & apps, that's the whole "Project Treble" thing Google was talking about a few years back. https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html https://android-developers.googleblog.com/2017/05/here-comes... But that's the easy non-answer. Abstractions can't add features. Like Windows 11 dropped support for old hardware not because the right abstractions weren't in place, but because you can't add things like a TPM in software. It needs full stack support. Similarly if it turns out a device driver had a bug in its implementation of the interface, you're kinda stuck with that. And the workaround may or may not be reasonable to put up with, if a workaround exists at all.
- StillBored 5y ago
  One doesn't need new features to "support" and older platform. You simply assure that code paths have fall back logic to deal with missing GPU functionality/etc and as you mention emulate it. The fact that this has worked for decades on lots of other OS's is proof of this. Iphone6's don't have facial recognition cameras but you can still unlock your phone/etc. Oh, and btw there are soft TPMs, which are the defaults on most new machines, and is probably part of the reason MS made it a requirement. But as others have shown by getting win11 to run without a TPM, it is entirely artificial, like when they decide not to ship IE/directX/whatever on an older OS. If a random hacker type can get it to work in a reasonable timeframe, there isn't really an excuse for MS not to just add the functionality with a little "your machine doesn't have a TPM so your not secure as you could be" notice somewhere. Its mostly laziness and market segmentation.
  - kllrnohj 5y ago
    That missing feature set bleeds into the developer experience and results in cries of "fragmentation." It's not "laziness" it has a real cost to 3p developers. And no, your claims of "just emulate it" is not accurate, nor is that how any other OS works. If you're missing a GPU feature on your Linux system (or, more likely, if your driver is even if your hardware supports it) it's up to everything that uses the GPU to not hit that path. Nothing is emulating it or in any way pretending to have a feature it doesn't "natively" have.
    - StillBored 5y ago
      Well of course, for somethings it becomes a least common denominator, but even for GPU's in the past the idea was that it was possible to use something like Mesa as the baseline and then accelerate the important/critical functionality in hardware. The original DX API was also designed like this. Its only once the market became basically a duopoly that the expectations shifted. Frankly, having a solid software reference model/fallback path likely makes peoples jobs easier because its easier to track down bugs by doing a/b testing. Oh, and BTW, you can likely boot your linux machine without your graphics card driver, and it will still be able to run your desktop/etc and simple openGL/etc applications like glxgears. How is that, because linux can and does fallback to software emulation, using... mesa.

jjulius 5y ago

Cool it on the whole "everyone needs a new phone every couple of years" thing, maybe? That's not the solution in and of itself, but it'd sure help. Not only would there be fewer variables in the hardware you have to support, but you help reduce e-waste.

dymk 5y ago
There's a big difference between 15 years and "couple of years", and on top of that, phones are particularly recyclable (and a good value to recycle, too! plenty of valuable metals in there).

yjftsjthsd-h 5y ago

Aggressive upstreaming and commoditization, mostly. When you build a device, you build it out of existing components where possible, and where it isn't you write drivers and immediately push to get them pulled up to the upstream Linux tree. You ship devices that always run run mainline kernels and little-to-no divergence from AOSP, that share as much code as possible (hence reusing components -> reusing drivers), you maintain a single ROM image with only the smallest changes per-device that you can possibly manage. And you staff a team that can maintain your software, but since you're sharing everything across devices - and with other vendors, since your drivers are tiny compared to the whole kernel+AOSP - you can maintain dozens of devices with only a little more effort than one or two. Oh, and I'd actually be on board with some sort of paid update program and/or crowdfunding after some point. Say 5 years of bug and security patches included in the price of the phone, and after that a small monthly fee that you use to keep up with the marginal cost of maintaining that device's unique drivers and code.