191–199 of 199 posts
Earlier quoted context omitted.
It's kinda self-deprecating humor; the (now ex) Tor developers I know use it. Nothing is ever 100% secure.
It's like the lesswrong folks; step one was accepting that there are too many flaws to fix everything, and then step two was to do our best anyways.
I'd hazard to say that every design is "flawed" in some regards: there's no way to achieve all desirable qualities and none of undesirable qualities. For one, some desirable qualities contradict each other. So "${thing} is flawed" is not precise enough; an interesting statement would be "${thing} is not the best choice for ${conditions}". A monolithic OS is not the best choice for a high-reliability system on unrelia…
The main point remains: server and desktop OS kernels are a critical piece of infrastructure, worthy of full machine checked verification. In this context, it should be pretty obvious that a design that fails to minimise the trusted computing base is flawed. Even if a kernel vulnerability is unlikely to kill any given user, the sum of all the crashes, hacks, patching effort… is huge. I bet my hat rewriting the entire…
Says who exactly?
Earlier quoted context omitted.
> QnX has shown the strength of microkernels for decades Could you elaborate on this one please?
QnX is so common that if you removed it from the industrial world the world would literally grind to a halt. Machinery and vehicles would stop moving, factories would stop producing, chemical plants would (hopefully!) shut down and airplanes would no longer take off (or would have a much harder time trying to land without the usual guidance systems), boats would drift and messages would stop being sent through many s…
Earlier quoted context omitted.
I actually looked into the HAL/HIDL docs before posting and found no evidence that they are there to implement drivers in userspace. As I understand it HALs and HIDL are used to provide a standardized way to implement new device features in a compatible way. So a vendor introduces a odor-sensor and can define an HIDL interface for the userspace to call the device driver provided in a kernel module. I do not see a req…
HIDL is the basis of Android IPC between processes, known as Binder. "Binderized HALs. HALs expressed in HAL interface definition language (HIDL). These HALs replace both conventional and legacy HALs used in earlier versions of Android. In a Binderized HAL, the Android framework and HALs communicate with each other using binder inter-process communication (IPC) calls. All devices launching with Android 8.0 or later m…
It if was, there would be documentation on how to write a userspace device driver, but there isn't.
Earlier quoted context omitted.
Because you just stopped at the kernel modules part and haven't spent time reading how HAL in Android actually works, starting at the HIDL link. There are two HALs in Android. The old HAL, previous to Treble, which was hardly used by OEMs. And the new HAL, which is enforced by Treble. On the new HAL, drivers are implemented as Android services using Android IPC via interfaces defined in HIDL, or by using the new shar…
I'll admit to not being steeped in the terminology, so feel free to educate me.. but some quick Googling suggests nobody else has called Treble a "microkernel." There are hits about Fuchsia (a totally separate OS), and some Android forks on microkernels. I'm guessing that the Treble modules expose the traditional /dev and /sys interfaces like before, and these new HALs talk to devices through those, right? Is that no…
Earlier quoted context omitted.
The main point remains: server and desktop OS kernels are a critical piece of infrastructure, worthy of full machine checked verification. In this context, it should be pretty obvious that a design that fails to minimise the trusted computing base is flawed. Even if a kernel vulnerability is unlikely to kill any given user, the sum of all the crashes, hacks, patching effort… is huge. I bet my hat rewriting the entire…
> Monolithic kernels are clearly the wrong tool for the job. Says who exactly?
> The security benefits of keeping a system’s trusted computing base (TCB) small has long been accepted as a truism, as has the use of internal protection boundaries for limiting the damage caused by exploits. Applied to the operating system, this argues for a small microkernel as the core of the TCB, with OS services separated into mutually-protected components (servers) – in contrast to “monolithic” designs such as Linux, Windows or MacOS. While intuitive, the benefits of the small TCB have not been quantified to date. We address this by a study of critical Linux CVEs, where we examine whether they would be prevented or mitigated by a microkernel-based design. We find that almost all exploits are at least mitigated to less than critical severity, and 40% completely eliminated by an OS design based on a verified microkernel, such as seL4.
If the effect is that huge, of course security trumps pretty much all other considerations. These are consumer OS kernels we're talking about. One that fails to more or less maximise security is obviously the wrong tool for the job. As the title of the paper suggests, in case you failed to read that as well.
Earlier quoted context omitted.
QnX is so common that if you removed it from the industrial world the world would literally grind to a halt. Machinery and vehicles would stop moving, factories would stop producing, chemical plants would (hopefully!) shut down and airplanes would no longer take off (or would have a much harder time trying to land without the usual guidance systems), boats would drift and messages would stop being sent through many s…
Is there an open source alternative to QnX?
Earlier quoted context omitted.
Just as a casual reader of this comment, a few tips: - The rhetoric about the world grinding to a halt isn't really pertinent and makes you look unreliable. Also, no, not "literally." I think what you're getting at is that it's chosen for high-reliability systems, with the implication being that it's chosen for its superior reliability(?) - But I say this because it sounds like you have some knowledge as to how this…
The world really would literally grind to a halt, you are severely under-estimating how common this particular OS is. It has been the embedded system of choice for a very large variety of applications, it is anything but obscure it is just obscure to those who spend their time working on web stuff but in industry you would come across it (and RTOS: https://rtos.com/ ) very often. Neither of those names will ring a be…
So, rather grind to a halt, it would all continue running in legacy mode, users would spend more money, and it gets supported or replaced. Lots of precedents for that sort of thing.
Between acquisition price and QNX's revenues, it's unlikely support will be terminated any time soon. We wont get to see the hypothetical tested unless RIM bankrupts with nobody acquiring and supporting their assets. That a losing company acquired QNX did worry me a bit, though.