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

A Kernel Hacker Meets Fuchsia OS

a13xp0p0v.github.io

Post reply on HN
Print view View original

31–40 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#31

Post by dec0dedab0de »

native_samples wrote: post #19

I think the more interesting thing here is the fact that so much code in their repository appears to be bit-rotted or half baked, despite being documented. KASLR is mentioned all over the place but doesn't work and the answer is "we know, it's there only to stop it bit-rotting". You need to patch the system to do kernel debugging because otherwise the toolchain hangs. Syscalls are documented as enforcing security rul…

It's hard not to feel like maybe Google has lost the ability to develop operating systems.

Did they ever have that ability? I know they did a bunch of work for Android/Chrome OS. But both of those are Linux, have they tried to develop an OS from scratch before fuschia?

Re: A Kernel Hacker Meets Fuchsia OS

#32

Post by layer8 »

kramerger wrote: post #25
bitwize wrote: post #23

The great thing about Fuchsia is it's like a Google version of Plan 9. The bad thing about Fuchsia is it's like a Google version of Plan 9.

The bad thing about Fuchsiais that it's a Google product. They may decide to kill it next week and switch to XNU or symbian or templeos and no one would be surprised.

That’s fine as long as it’s open source and a self-contained local piece of software (as Fuchsia is). The problem with Google killing products is that they’re closed source and/or require huge server resources and/or ML models.

Re: A Kernel Hacker Meets Fuchsia OS

#33

Post by tyingq »

nine_k wrote: post #27

My takeaway from the article is that Fuchsia exposes a capability-based interface externally, but uses the old kind of privilege-checking inside the kernel. Once a single sloppy check was found, the game was over: a privilege escalation and planting of arbitrary code into the kernel followed. Did I miss anything?

Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?

Re: A Kernel Hacker Meets Fuchsia OS

#34

Post by layer8 »

5e92cb50239222b wrote: post #11
ge96 wrote: post #9

Earlier quoted context omitted.

It's weird in my later 20s I started doing this, writing homophones. I at least get my then/their/effect right still.

I think this mostly happens to native English speakers for some unimaginable reason. I don't remember ever making this mistake (but do remember plenty others to make up for it), and can't imagine myself doing it. Yet it happens to native speakers all the time.

As a nonnative English speaker (actually mostly reader/writer/listener), I started doing that at some point (many years after English proficiency), to my own dismay.

Re: A Kernel Hacker Meets Fuchsia OS

#35

Post by [deleted] »

michaelmarkell wrote: post #14
rosetremiere wrote: post #12

Earlier quoted context omitted.

I would guess that the difference native/foreign is simply due to the way language is learned: for native speakers, it's first and mostly orally. This doesn't explain a later appearance of mistakes though…

I right a lot less now then I did as a kid, so maybe it’s about just staying sharp

[deleted]

Re: A Kernel Hacker Meets Fuchsia OS

#37

Post by shp0ngle »

native_samples wrote: post #19

I think the more interesting thing here is the fact that so much code in their repository appears to be bit-rotted or half baked, despite being documented. KASLR is mentioned all over the place but doesn't work and the answer is "we know, it's there only to stop it bit-rotting". You need to patch the system to do kernel debugging because otherwise the toolchain hangs. Syscalls are documented as enforcing security rul…

I think you are downvoted because you touch on the BLM/Asian Pacific stuff, which tickles people. But yeah you are also very right.

Re: A Kernel Hacker Meets Fuchsia OS

#38

Post by nine_k »

tyingq wrote: post #33
nine_k wrote: post #27

My takeaway from the article is that Fuchsia exposes a capability-based interface externally, but uses the old kind of privilege-checking inside the kernel. Once a single sloppy check was found, the game was over: a privilege escalation and planting of arbitrary code into the kernel followed. Did I miss anything?

Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?

Not necessarily.

The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you).

In other words, a capability is like a key in a hash table, and unlike an index in an array.

Re: A Kernel Hacker Meets Fuchsia OS

#39

Post by jackdaniel »

tyingq wrote: post #33
nine_k wrote: post #27

My takeaway from the article is that Fuchsia exposes a capability-based interface externally, but uses the old kind of privilege-checking inside the kernel. Once a single sloppy check was found, the game was over: a privilege escalation and planting of arbitrary code into the kernel followed. Did I miss anything?

Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?

It is more like:

(caller_capabilities[WHATEVER_CAPABILITY])(...);

when the capability is not present, then you get no_method_found or something similar.

Re: A Kernel Hacker Meets Fuchsia OS

#40

Post by why_only_15 »

nine_k wrote: post #38
tyingq wrote: post #33

Earlier quoted context omitted.

Not familiar with capability-based practices, but wouldn't there always be a "if (has_this_capability(WHATEVER_CAPABILITY))" at the very bottom...one that could be sloppy? Doesn't something, somewhere do a comparison?

Not necessarily. The core idea of capabilities is more like having a URL to a Web page. Using the URL (the capability), you can access the contents of the page. Inside the contents, you can possibly find other URLs (more privileges granted to you). But the URL happens to be something like an UUID, or a short link; looking at it, you cannot derive another URL (discover another "capability", not granted to you). In oth…

Interesting. Is this in practice implemented as just capabilities being large numbers so it's impractical to guess them, or does the kernel have a table with all of a process's capabilities and when a message is sent to a process with capabilities the kernel adds them to the table?

That is -- are capabilities just pieces of data in a message you can detect and try to use, or do they have to be added explicitly to a message to send them

Post reply on HN