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

291–296 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#291

Post by Commodore63 »

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?

Capability based operating systems require that your program possess something, like a handle, in order to do something privileged. Don't have the handle, can't do the thing. It's not about consulting ACLs or bitmasks or whatever.

Re: A Kernel Hacker Meets Fuchsia OS

#292

Post by conioh »

zahllos wrote: post #106
giyanani wrote: post #49

Earlier quoted context omitted.

I’m not sure how fuschia does it, or how feature-based capabilities work, but Cheri[1] uses capabilities for memory management and isolation. It uses a couple of techniques, like wide/tagged pointers, object ids, and a special hardware managed bit to track illegal modifications. If I had to hazard a guess, those object ids are probably useful for general capability systems. I think apple (maybe as just an arm feature…

> I think apple (maybe as just an arm feature?) can do encrypted pointers, with a per application key tracked by the kernel. ARM has added both pointer authentication codes and memory tagging extensions to their ISA, from (I think) ARMv8.5-A. Apple are the only ones to implement silicon that supports PAC that anyone can buy today but a) this will change fast and b) I might've missed something else. I wouldn't say "en…

> ARM has added both pointer authentication codes and memory tagging extensions to their ISA, from (I think) ARMv8.5-A. Apple are the only ones to implement silicon that supports PAC that anyone can buy today but a) this will change fast and b) I might've missed something else.

I'm not aware of other generally available chips with pointer authentication. The Qualcomm Snapdragon 8cx Gen 3 supposedly support PA. The Lenovo ThinkPad X13s supposedly contains it, but when will it actually be commercially available is anyone's guess.

Also, I think it's ARMv8.3.

Re: A Kernel Hacker Meets Fuchsia OS

#293

Post by jhugo »

pasabagi wrote: post #289
jhugo wrote: post #259

Earlier quoted context omitted.

I think the issue is simpler than the above discussion. I have no idea what to think about BLM. I'm not American, so it's not part of my zeitgeist. I hear all kinds of differing opinions about it from Americans. One thing is clear to me: "BLM good" is more complicated than just "racism bad". When I see something supporting BLM in tech documentation, it's confusing (I don't know why it's relevant to tech documentation…

My guess is the only reason why Europe has a more sophisticated discussion about race and racism now than it did in the 50's is because of American influence. I say this as a European. There simply are not the sizeable minorities in europe to push these issues into the public discourse, and as such, without exposure to US culture, most people's views on race tend to be only lightly modified from traditional views, wh…

Yes, I think you're right. And in many parts of Europe, there still isn't much sophisticated discussion about race and racism. (That's my observation as an outsider though; I'm not European.)

But pro-BLM is not the same thing as anti-racism, as I noted.

If you want to write down your values and plaster them at the top of every page of your tech documentation, I'll think that's a bit weird but I guess I'll mostly be fine with it?

But if you distill your advertised values into a single message of support for a political group that is virtually unknown in most of the world, that's more complicated. It makes it harder to understand the message, and it gives it an air of exclusivity, as the real meaning of the message is only understood to a subset of the people who see it.

Re: A Kernel Hacker Meets Fuchsia OS

#294

Post by pasabagi »

jhugo wrote: post #293
pasabagi wrote: post #289

Earlier quoted context omitted.

My guess is the only reason why Europe has a more sophisticated discussion about race and racism now than it did in the 50's is because of American influence. I say this as a European. There simply are not the sizeable minorities in europe to push these issues into the public discourse, and as such, without exposure to US culture, most people's views on race tend to be only lightly modified from traditional views, wh…

Yes, I think you're right. And in many parts of Europe, there still isn't much sophisticated discussion about race and racism. (That's my observation as an outsider though; I'm not European.) But pro-BLM is not the same thing as anti-racism, as I noted. If you want to write down your values and plaster them at the top of every page of your tech documentation, I'll think that's a bit weird but I guess I'll mostly be f…

> But pro-BLM is not the same thing as anti-racism, as I noted.

I guess for me the BLM movement goes back to the roots of the struggle for civil rights in the west. The west has always had this tension between a strong history of formal equality (probably going back to the Roman citizenship tradition) and an equally strong tradition of slavery and segregation.

You can go back to the 1800's anti-slavery campaign slogan 'Am I not a man and a brother?', or to the MLK-era billboard 'I am a man', to 'Black Lives Matter', and you can see the basic line of attack is the same. Equally, every step of the way, their opponents have always said that contemporary forms of anti-racism are not really connected to the past forms, they're going too far, even though their slogans and basic politics are more or less the same.

If you're not from the west, I guess you can say, 'not my dog, not my race', but I think just as nations around the world have adopted western models of economics, and western models of citizenship, they also have to wrestle with the implications those models have for minority groups within their polities.

> But if you distill your advertised values into a single message of support for a political group that is virtually unknown in most of the world, that's more complicated.

I guess in the 70's, villagers in China knew about Huey P. Newton, but probably had a very shaky understanding of McDonalds. If there's one cultural export from America I'm rather pleased about, its the great work of their anti-racism campaigners. I'd be quite happy if the BLM message was as ubiquitous as the Coca Cola message, for instance.

Re: A Kernel Hacker Meets Fuchsia OS

#295

Post by conioh »

badRNG wrote: post #142
staticassertion wrote: post #110

Earlier quoted context omitted.

People say this about a lot of security things. Ultimately, a lot of security is about constraining systems, and that makes people nervous. When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices. And for the same exact reason that I have less control over my phone, I also trust it radically more for my current threat mode…

>When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices. Some of the easiest phones to do this to today, namely the Pixel phones, are also some of the most secure stock Android phones on the market. Freedom and security are not mutually exclusive.

> > When I got my first Android phone I could root it pretty trivially and run a fully customized ROM, these days it's not really practical on many devices.

> Some of the easiest phones to do this to today, namely the Pixel phones, are also some of the most secure stock Android phones on the market. Freedom and security are not mutually exclusive.

What's so safe about it once you unlock the bootloader and install a custom ROM / rootkit (since by disabling boot verification you don't actually know that what you're booting is the custom ROM you intended to to boot or something else)?

Re: A Kernel Hacker Meets Fuchsia OS

#296

Post by fay59 »

DannyBee wrote: post #232
fay59 wrote: post #224

Earlier quoted context omitted.

What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel ins…

I admire your optimism, but the notion that missing access checks are somehow less dangerous in a memory safe language is nonsense on its face. Yes, this particular one enabled a defeat of ASLR, but so what? Missing access checks enable privilege escalation no matter what the language. Your claim that "has well-definable consequences" is equally true in C++ as anywhere else. Whether you miss your access check in rust…

No, logic bug consequences are fundamentally different from memory corruption bugs. A bug with an access check for one resource in the kernel means you get access to that specific resource. A missing bounds check in the kernel—anywhere in the kernel—means you get arbitrary code execution. Sure, _sometimes_ you can escalate from one resource to another with an access check issue, but that’s a _sometimes_. One memory corruption bug _anywhere_ defeats the protection of _all resources, all the time_. Not only that, but memory corruption bugs have well-understood exploit recipes that attackers can make once and reuse any time they find a new bug to save work, whereas an attacker has to write a new distinct exploit for most logic bugs.

There is no equivalence to make. Memory corruption bugs are unambiguously, unequivocally better exploitation primitives than logic bugs.

No one is claiming that memory-safe languages solve logic problems. The claim is that most memory corruption bugs are conveniently exploitable and any exploit can reach for anything in the address space, and logic bugs often can’t. You could as well say that you’d rather promote chess pawns to knights instead of queens. Like, that makes sense sometimes, but it’s a bad default.

Post reply on HN