> Mitigations that are Linux only and hardly effective, hence why Android is now going to require hardware pointer validation on Android 11.
What do you mean by Linux only? Modern mitigations are very effective at increasing cost of exploitation and the underlying concepts are platform-independent - Windows, macOS and iOS follow similar approaches with similar results. If anything, Linux (both the kernel, and various userlands) has been trailing behind.
Pointer authentication is just the logical next step, just like CPU features like SMEP and SMAP superseded software-only implementations like PaX KERNEXEC/UDEREF. And yes, even hardware pointer authentication can be bypassed if someone tries hard enough.
Without moving to a memory safe language, memory corruption exploits will always be possible (just more and more expensive), and I'd love to use an OS kernel written in Rust. It has been exhaustively proven that even the world's best engineering teams are incapable of consistently writing safe C/C++ code - any line of C code exposed to untrusted input is a liability.
But meanwhile, I'm happy that the industry is finally investing in mitigations that kill some classes of bugs, and raise the bar for others, rather than only hunting for and fixing individual bugs.
> Protobufs, gRPC are only a thing if one is on Google land and even then quite primitive tooling, versus what those other protocols offered.
The simplicity, even at the cost of expressivity, are one of the best parts of Protobuf and gRPC. The unbounded complexity and feature set of approaches like SOAP or CORBA is the reason why they've failed.
gRPC has seen a lot of adoption outside of the Google ecosystem.
We probably both agree that REST and JSON were a mistake.
> Desktop apps are quite alive, specially on enterprise and domains like lifesciences laboratory automation, medical monitoring devices and plenty of other areas where a browser just doesn't cut it.
Those are highly niche use cases, and the UI for many of these will eventually move to the web platform, too. Even my dentist's office, which used to run on an antique Win32 application, is now using a next-generation web application built by the same vendor, that supersedes the Windows application. Hosted on a local server, not the cloud.
Very few applications actually need low level hardware access, and sandboxing won't be a concern for these since they're typically the only thing running on the machine that's worth protecting to begin with.
> ChromeOS hardly counts as Linux, specially since not all devices are Crostini capable, and yes Steam hardware survey puts it at ruffly 1%.
Why wouldn't it count as Linux? It runs on the Linux kernel and with a slightly exotic, but fully open source userland. You can modify it and run it on your device (at the expense of boot integrity protection). ChromeOS shares a lot of code with other Linux distributions (like ModemManager, CUPS, the new Chrome renderer, a lot of work on upstreaming kernel driver improvements...).
Any recent ChromeOS device supports Crostini. If it doesn't, it's for reasons like "the CPU has no VT-x support", "this is a 32bit ARM CPU" or a potato CPU.
Steam hardware survey data is not representative.
> I gave up on hunting for Linux hardware ages ago, Apple and Microsoft OSes and related hardware keep me happy when doing graphics programming.
Agreed - graphics programming, especially the high performance kind, is best done on Windows. The tooling is just so much better. But for the kind of work I do - security research and systems engineering - GNU/Linux is perfect and hardware support is great.
> As you see, we have to agree to disagree.
Thank you for this pleasant and interesting discussion, even if we ended up disagreeing :)
What do you mean by Linux only? Modern mitigations are very effective at increasing cost of exploitation and the underlying concepts are platform-independent - Windows, macOS and iOS follow similar approaches with similar results. If anything, Linux (both the kernel, and various userlands) has been trailing behind.
Pointer authentication is just the logical next step, just like CPU features like SMEP and SMAP superseded software-only implementations like PaX KERNEXEC/UDEREF. And yes, even hardware pointer authentication can be bypassed if someone tries hard enough.
Without moving to a memory safe language, memory corruption exploits will always be possible (just more and more expensive), and I'd love to use an OS kernel written in Rust. It has been exhaustively proven that even the world's best engineering teams are incapable of consistently writing safe C/C++ code - any line of C code exposed to untrusted input is a liability.
But meanwhile, I'm happy that the industry is finally investing in mitigations that kill some classes of bugs, and raise the bar for others, rather than only hunting for and fixing individual bugs.
> Protobufs, gRPC are only a thing if one is on Google land and even then quite primitive tooling, versus what those other protocols offered.
The simplicity, even at the cost of expressivity, are one of the best parts of Protobuf and gRPC. The unbounded complexity and feature set of approaches like SOAP or CORBA is the reason why they've failed.
gRPC has seen a lot of adoption outside of the Google ecosystem.
We probably both agree that REST and JSON were a mistake.
> Desktop apps are quite alive, specially on enterprise and domains like lifesciences laboratory automation, medical monitoring devices and plenty of other areas where a browser just doesn't cut it.
Those are highly niche use cases, and the UI for many of these will eventually move to the web platform, too. Even my dentist's office, which used to run on an antique Win32 application, is now using a next-generation web application built by the same vendor, that supersedes the Windows application. Hosted on a local server, not the cloud.
Very few applications actually need low level hardware access, and sandboxing won't be a concern for these since they're typically the only thing running on the machine that's worth protecting to begin with.
> ChromeOS hardly counts as Linux, specially since not all devices are Crostini capable, and yes Steam hardware survey puts it at ruffly 1%.
Why wouldn't it count as Linux? It runs on the Linux kernel and with a slightly exotic, but fully open source userland. You can modify it and run it on your device (at the expense of boot integrity protection). ChromeOS shares a lot of code with other Linux distributions (like ModemManager, CUPS, the new Chrome renderer, a lot of work on upstreaming kernel driver improvements...).
Any recent ChromeOS device supports Crostini. If it doesn't, it's for reasons like "the CPU has no VT-x support", "this is a 32bit ARM CPU" or a potato CPU.
Steam hardware survey data is not representative.
> I gave up on hunting for Linux hardware ages ago, Apple and Microsoft OSes and related hardware keep me happy when doing graphics programming.
Agreed - graphics programming, especially the high performance kind, is best done on Windows. The tooling is just so much better. But for the kind of work I do - security research and systems engineering - GNU/Linux is perfect and hardware support is great.
> As you see, we have to agree to disagree.
Thank you for this pleasant and interesting discussion, even if we ended up disagreeing :)