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

191–200 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#191

Post by skavi »

Banana699 wrote: post #147
skavi wrote: post #127

Earlier quoted context omitted.

You’re comment and a sibling both express that these messages are off-putting to international audiences? Why is that? BLM originated in the US, but black people definitely experience racism elsewhere. The movement is not necessarily US exclusive. I’ve seen plenty of tech companies with Ukraine banners on their websites, and have not seen a single criticism. Wouldn’t such banners exclude US developers under that logi…

>You’re comment and a sibling both express that these messages are off-putting to international audiences? Non-American distinct from both of them here: They're right. >black people definitely experience racism elsewhere Persuambly you think BLM is a generic "Racism Bad" message, so 3 things to say about this 1- BLM is not a generic "Racism Bad" message. It's the name of a movement whose leaders used donor money to a…

I do feel that BLM is a worthy cause to support. This is mainly because I feel the movement can be seen separately from any formal organizations or individual people. I understand how you may disagree.

Regardless, the real disagreement seems to be in where it is appropriate to represent the movements you believe in.

Even granting that a technical document page may not be the best place for such advertising, I still do not understand why the presence of these messages would offend an international audience.

If they are truly irrelevant, then surely it should be at worst unsightly?

Re: A Kernel Hacker Meets Fuchsia OS

#192

Post by Rusky »

staticassertion wrote: post #182
Rusky wrote: post #155

Earlier quoted context omitted.

It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. (One process can request that the kernel transfer it to another process, which I guess you might be referring to? I'm not familiar with Fuchsia specifically here but generally speaking capability-based desig…

> It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. No, this is incorrect. Let's just quote wikipedia, > A capability (known in some systems as a key) is a communicable, unforgeable token of authority. communicable . It is practically the whole point that y…

I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzzy emulation"- you can in principle forge a URL in a way that you could never forge a file handle.

Obviously if you communicate the actual capability itself to someone you didn't intend to, that would be bad. But that's more of a question of API design- even fork is, in this sense, asking for the capability to be transferred. This is a very different problem than the one Dropbox has- no amount of random guessing, or side channel information leaks, or anything else like that, is going to land a capability in another process's kernel table.

Re: A Kernel Hacker Meets Fuchsia OS

#193

Post by corrral »

fartcannon wrote: post #186
corrral wrote: post #179

Earlier quoted context omitted.

I have almost zero interest in haxoring my phone, and just want it to always work and not let 3rd parties steal my info, automatically. And I'm a life-long computer geek who's done professional mobile development. Most people care even less than I do. They just want it to work, because computers aren't their life, they just use them to get stuff done, or when someone else tells them they have to. Would it be sort of…

For one, being able to use your computer/phone like a computer isn't 'haxoring'. Jesus. And second, Apple _lets you_ now (mostly anyways), because people with sense still raise a stink. So, basically, you're welcome. Stop screwing it up for the rest of us.

What's getting screwed up? It's cheaper and easier than ever to acquire a wide-open computer platform. There are also more of them than ever. There's just also a couple new categories of computing appliance—which is nowhere near being a new thing—that weren't around before.

Re: A Kernel Hacker Meets Fuchsia OS

#194

Post by josephcsible »

vander_elst wrote: post #154

Disclaimer: I made some contributions to Fuchsia and I am clearly biased. I am not sure why there's so much negativity around Fuchsia. From a technical point of view it's finally a serious attempt to do something new in the OS space. It might not be the right and perfect answer, but it might introduce new paradigms and maybe some fork of the project might be able to provide additional benefits for end users down the…

> I am not sure why there's so much negativity around Fuchsia.

Because the real reason for its existence seems to be to slowly kill open source, by not requiring hardware vendors to provide kernel/driver source anymore.

Re: A Kernel Hacker Meets Fuchsia OS

#195

Post by josephcsible »

_k9eq wrote: post #173
hosteur wrote: post #160

Earlier quoted context omitted.

> I am not sure why there's so much negativity around Fuchsia. Easy: this is not the future we want. We don’t trust google. We don’t want an OS designed to further their goal of total control and surveillance capitalism.

> We don’t want an OS designed to further their goal of total control and surveillance capitalism. What parts of the operating system design do this?

The license, by allowing proprietary forks.

Re: A Kernel Hacker Meets Fuchsia OS

#196

Post by josephcsible »

staticassertion wrote: post #110
azalemeth wrote: post #105

Fuchsia still makes me deeply nervous inside. I get that linux has plenty of problems, but it really feels like Google have started to write an OS for the purposes of (a) having better remote control over the software that users run, and (b) being able to be free of the GPL. Security is the panacea that lets this happen, but I'm really not sure that it will inherently be better: iOS has effectively this model and it…

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…

What do TPMs do that's actually important?

Re: A Kernel Hacker Meets Fuchsia OS

#197

Post by staticassertion »

Rusky wrote: post #192
staticassertion wrote: post #182

Earlier quoted context omitted.

> It doesn't matter if the value is leaked, because it's meaningless to another process- like a file descriptor, it's just an entry in a table in the kernel, so it can only be used by the process it was granted to. No, this is incorrect. Let's just quote wikipedia, > A capability (known in some systems as a key) is a communicable, unforgeable token of authority. communicable . It is practically the whole point that y…

I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzzy emulation"- you can in principle forge a URL in a way that you could never forge a file handle. Obviously if you communicate the actual capability itself to someone you didn't intend to, that would be ba…

Yes, accidentally sharing a capability is a leak. If I accidentally printed out a capability it would be 'leaked' and anyone who reads that capability now has obtained it an dcan use it.

> you can in principle forge a URL in a way that you could never forge a file handle.

Maybe it would be better to not talk about fs apis, because they're not really capability based, so I suspect that's the confusion.

The point is that if someone has a capability, they have that capability. There is no additional access control or checking in a capability based system. You absolutely have to consider things like rotation and revocation.

Re: A Kernel Hacker Meets Fuchsia OS

#198

Post by fay59 »

DannyBee wrote: post #137
fay59 wrote: post #116

Earlier quoted context omitted.

The intent of the post isn’t to claim that any Fuschia device currently sold is vulnerable. Unless Fuschia never graduates to running third-party code, that seemed like the right assessment to me.

Sure - but he also added the vulnerability he exploited in the first place?

That’s not really a “but” to the comment, which was that you need to find one bug and it’s game over. We’ve known for a long time that best practices aren’t enough to prevent memory corruption in large enough C++ code bases, so it’s likely a motivated attacker would eventually find something.

Re: A Kernel Hacker Meets Fuchsia OS

#199

Post by josephcsible »

corrral wrote: post #193
fartcannon wrote: post #186

Earlier quoted context omitted.

For one, being able to use your computer/phone like a computer isn't 'haxoring'. Jesus. And second, Apple _lets you_ now (mostly anyways), because people with sense still raise a stink. So, basically, you're welcome. Stop screwing it up for the rest of us.

What's getting screwed up? It's cheaper and easier than ever to acquire a wide-open computer platform. There are also more of them than ever. There's just also a couple new categories of computing appliance—which is nowhere near being a new thing—that weren't around before.

> There are also more of them than ever.

This is super misleading. There's only slightly more wide-open platforms now than there ever were, but there's way, way more locked-down ones.

> There's just also a couple new categories of computing appliance

A couple?

Re: A Kernel Hacker Meets Fuchsia OS

#200

Post by Rusky »

staticassertion wrote: post #197
Rusky wrote: post #192

Earlier quoted context omitted.

I think we're just talking past each other- by "leak" I was talking about something like accidentally sharing an fd number, not actually communicating the capability itself. This is how Dropbox's approach is a "fuzzy emulation"- you can in principle forge a URL in a way that you could never forge a file handle. Obviously if you communicate the actual capability itself to someone you didn't intend to, that would be ba…

Yes, accidentally sharing a capability is a leak. If I accidentally printed out a capability it would be 'leaked' and anyone who reads that capability now has obtained it an dcan use it. > you can in principle forge a URL in a way that you could never forge a file handle. Maybe it would be better to not talk about fs apis, because they're not really capability based, so I suspect that's the confusion. The point is th…

I'm specifically talking about Fuchsia and other kernel-based capabilities here. You fundamentally cannot print out that kind of capability in any way that matters- the only thing that determines whether a process has it is the table in the kernel, not whether it can produce a particular bit pattern.

In this sense, fs APIs are a fine example, as long as you keep the ls/.. caveats in mind. If you have a file descriptor for something inaccessible through the global file system namespace, then the only way to grant that to another process is via specifically-designed APIs like domain sockets or fork.

As I said in my first comment, there are of course other reasons you might want to revoke a capability. But unlike Dropbox URLs, true capabilities are unforgeable, so you don't need to rotate them out simply to make them harder to guess- they're already unguessable.

Post reply on HN