Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Jury Is In: Monolithic OS Design Is Flawed [pdf]

ts.data61.csiro.au

Post reply on HN
Print view View original

181–190 of 199 posts

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#181

Post by jacquesm »

alexandercrohde wrote: post #174
jacquesm wrote: post #141

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…

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 bell for people who spend their days with your usual web toolsets.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#182

Post by monocasa »

pjmlp wrote: post #172
renox wrote: post #167

OK so seL4 is safer than Linux, that's not really news.. I have questions about seL4 though: is it able to manage several multicore CPU efficiently? What about power management, does it work?

Given that it is responsible for powering many embedded systems deployed into production, yes.

They only added multicore support in the past year, and it contains no power management code beyond sleeping in the idle loop.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#183

Post by monocasa »

pjmlp wrote: post #128
ysleepy wrote: post #121

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…

Binder allows for endpoints in kernel space.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#184

Post by gnufx »

Contrary to what's written about microkernel speed: Systems I used in the '80s to great effect used at least the moral equivalent of a microkernel ("Nucleus"). They were fast (compared with VAXen etc.) for interactive use and supported real-time processes. (Some visitors thought context switching was a bit slow, assuming "microseconds" meant "milliseconds".) The filesystem was fast enough to dispel the assumption a "database" was always required for speedy experimental data access rather than a file per spectrum.

https://en.wikipedia.org/wiki/OS4000

The performance wasn't just because Nucleus initially was in hard/firmware; two later software implementations were performant (on faster hardware). Also, as the article is about security: at least the original Nucleus also supported an A1/B3-level secure OS.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#185

Post by pjmlp »

monocasa wrote: post #182
pjmlp wrote: post #172

Earlier quoted context omitted.

Given that it is responsible for powering many embedded systems deployed into production, yes.

They only added multicore support in the past year, and it contains no power management code beyond sleeping in the idle loop.

So I wonder how do those devices manage themselves.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#186

Post by pjmlp »

monocasa wrote: post #183
pjmlp wrote: post #128

Earlier quoted context omitted.

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…

Binder allows for endpoints in kernel space.

Of course, otherwise how would they support passthrough legacy HALs for devices upgrading to Oreo as described on the documentation?

Interprocess RPC is only for Oreo and newer.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#187

Post by Sporktacular »

Dylan16807 wrote: post #179
Sporktacular wrote: post #173

Earlier quoted context omitted.

I don't need to - the paper just did that by conflating monolithic kernels with security failures that were avoidable.

That doesn't mean they are the only way to get security.

If you can afford formal verification and application programmers also fluent in hardware level coding, you can probably afford more RAM.

I'd want to see a solid paper comparing the security of the approach you mention to a microkernel+app. Until then we have this.

But agreed, there are other ways, of varying practicality, to achieving security.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#188

Post by gnulinux »

nkkollaw wrote: post #40
gnulinux wrote: post #30

Earlier quoted context omitted.

Isn't GNU/Linux (so, no Android) alone most popular OS too, thanks to servers and cloud? Any data on this?

Ah, possible--but not consumer.

Well, by using the internet, pretty much everyone is a consumer, even though they don't necessarily know of it.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#189

Post by monocasa »

pjmlp wrote: post #186
monocasa wrote: post #183

Earlier quoted context omitted.

Binder allows for endpoints in kernel space.

Of course, otherwise how would they support passthrough legacy HALs for devices upgrading to Oreo as described on the documentation? Interprocess RPC is only for Oreo and newer.

The current HAL works via dynamic libraries that get loaded into your process and talk to kernel space with a platform specific API. The passthrough support is just opening both sides in the same process, loading those legacy libraries, and wrapping the libraries in the treble API. So it actually uses IPC where both sides are in user space. That's what they mean when they describe it as 'in process' in the documentation.

Going forward, I expect the vendors to modify their kernel drivers to export the treble API over binder IPC directly while in kernel space.

So I wouldn't be surprised if it ends up that interprocess RPC only ebds up getting used in systems before Oreo.

Re: The Jury Is In: Monolithic OS Design Is Flawed [pdf]

#190

Post by monocasa »

pjmlp wrote: post #185
monocasa wrote: post #182

Earlier quoted context omitted.

They only added multicore support in the past year, and it contains no power management code beyond sleeping in the idle loop.

So I wonder how do those devices manage themselves.

They dont. You don't need power management for a lot of embedded systems that are high assurance. Power is generally plentiful in high assurance situations for a lot of reasons.
Post reply on HN