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

251–260 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#251

Post by staticassertion »

Rusky wrote: post #240
staticassertion wrote: post #238

Earlier quoted context omitted.

So to recap, a capability is a value that represents authorization. The value must not be forgeable, the value must be communicable. If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability. Delegation is not forgery. Forgery would be an entity creating a token without the token being delegated to that entity. Guessing is forgery, b…

Yes- the thing you didn't mention is the distinction I'm making between Dropbox URLs/UUIDs/etc and fds/Fuchsia capabilities, which is that the former are bit patterns and the latter are pieces of state in a trusted kernel. The attack surface of "bit pattern" capabilities is much larger than that of "trusted state" capabilities- even if you can't practically guess one, all you need to break it is to discover its bit p…

I wouldn't call it attack surface, I would call it a threat model. And yes, the threat model of capabilities includes the fact that knowledge of the capability connotes the capability. If it didn't, it wouldn't be a capability.

Re: A Kernel Hacker Meets Fuchsia OS

#252

Post by staticassertion »

formerly_proven wrote: post #250
staticassertion wrote: post #238

Earlier quoted context omitted.

So to recap, a capability is a value that represents authorization. The value must not be forgeable, the value must be communicable. If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability. Delegation is not forgery. Forgery would be an entity creating a token without the token being delegated to that entity. Guessing is forgery, b…

> If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability. You're taking "communicable" too literally. It doesn't mean "literally giving someone else this bytestring and now they can do it, too". It means "there is a way to give someone else the capability". SCM_RIGHTS is such a way to communicate capabilities between processes. Fu…

No, it does not mean there is "a way", it means that the name is the permission. Period. That is what a capability is. If the name is not the permission, it is not a capability.

Re: A Kernel Hacker Meets Fuchsia OS

#253

Post by wheelerof4te »

dmitrygr wrote: post #24

The people who work on fuchsia are very good engineers - I’ve worked with many of them in person. But the project itself has always been a staff retention project. It only existed to keep said engineers from going to a competitor. I don’t know how any understanding of fuchsia is possible without this crucial fact

If I were a CEO of a multi-bilion $ company, I would definitely put my best engineers on a long-term project like Fuchsia.

Google is one of few companies with capacity, capital and mindshare to make these kinds of projects.

Re: A Kernel Hacker Meets Fuchsia OS

#254

Post by pabs3 »

pjmlp wrote: post #222
josephcsible wrote: post #216

Earlier quoted context omitted.

> Linux already doesn't require hardware vendors to provide driver sources. Yes it does. The GPL literally does exactly that.

It is sooo successful on the Android, IoT ecosystems.

That will probably change if this lawsuit against Vizio succeeds:

https://sfconservancy.org/copyleft-compliance/vizio.html

If it does, then any recipient of Linux will be able to sue for compliance.

Re: A Kernel Hacker Meets Fuchsia OS

#255

Post by monocasa »

why_only_15 wrote: post #40
nine_k wrote: post #38

Earlier quoted context omitted.

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 m…

It's per process like the file descriptor tables under most kernels. Knowing that some other process has a certain socket open as fd '5' on their fd table doesn't give you enough information to attach the same socket to your fd table at fd 5 or otherwise.

Re: A Kernel Hacker Meets Fuchsia OS

#256

Post by daptaq »

josephcsible wrote: post #195
_k9eq wrote: post #173

Earlier quoted context omitted.

> 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.

But that is a matter of licensing, not design (which I underdtand to be things like the capability system or the micro kernel). I'd prefer a Copyleft license too, but 1. it is not a suprise that Google is not interested in that 2. even with Android they are able to restrict the user.

Re: A Kernel Hacker Meets Fuchsia OS

#257

Post by monocasa »

staticassertion wrote: post #252
formerly_proven wrote: post #250

Earlier quoted context omitted.

> If I'm unable to convey authorization by giving you the token, it is not a capability. If I am able to guess the token, it is not a capability. You're taking "communicable" too literally. It doesn't mean "literally giving someone else this bytestring and now they can do it, too". It means "there is a way to give someone else the capability". SCM_RIGHTS is such a way to communicate capabilities between processes. Fu…

No, it does not mean there is "a way", it means that the name is the permission . Period. That is what a capability is. If the name is not the permission, it is not a capability.

It can mean what the parent is talking about, and does in this case. It's an older morph of capability based security than the newer crypto enforced name concept, but equally valid.

You can read more about it in Capability Based Computer Systems by Henry M Levy. The Hydra MMP, GE-645, and iAPX 432 are older implementions of this concept in hardware.

In both cases (TCB table enforced and crypto one way function enforced) the name is the capability, but in a kernel (or hardware) table enforced method that's interpreted to mean that you have permission to access the object by having a simply having reference to it in your descriptor table.

You can see this also in KeyKOS, EROS, Coyotos, XOK, and SeL4 among many other capability based kernels. They don't give you a capability just because you got access to a global name to the backing object; the whole shtick for them is there is no global names for objects, only descriptor tables.

Re: A Kernel Hacker Meets Fuchsia OS

#258

Post by staticassertion »

monocasa wrote: post #257
staticassertion wrote: post #252

Earlier quoted context omitted.

No, it does not mean there is "a way", it means that the name is the permission . Period. That is what a capability is. If the name is not the permission, it is not a capability.

It can mean what the parent is talking about, and does in this case. It's an older morph of capability based security than the newer crypto enforced name concept, but equally valid. You can read more about it in Capability Based Computer Systems by Henry M Levy. The Hydra MMP, GE-645, and iAPX 432 are older implementions of this concept in hardware. In both cases (TCB table enforced and crypto one way function enforc…

What you're referring to is how operating systems maintain the integrity of capabilities. This is addressed directly in 'Capability Based Computer Systems'. I would direct you to chapter 1 section 1.1.

> A capability thus provides addressing and access rights to an object.

> a program cannot access an object unless its capability list contains a suitably privileged capability for the object.

> Capability system integrity is usually maintained by prohibiting direct program modification of the capability list. The capability list is modified only by the operating system or the hardware.

> Thus, a program can execute direct control over the movement of capabilities and can share capabilities, and therefore, objects, with other programs and users.

You can think of capabilities lists as kernel managed namespaces if you'd like. Maybe that would help clear things up.

Re: A Kernel Hacker Meets Fuchsia OS

#259

Post by jhugo »

skavi wrote: post #249
Banana699 wrote: post #206

Earlier quoted context omitted.

>then surely it should be at worst unsightly? What me and other people are trying to get across to you, is that you only feel this way because you support the cause. The practice of filling every place and institution with your partisan beliefs is a sign of disrespect, essentially a power move. "You're here to read up on an OS, but joke on you, you actually can't escape the all-pervasive hand of my religion. Here's s…

I really can’t see the equivalency between a political stance (imo a movement for racial equality) and religion. The former mixes, often by necessity, with technical documents all the time. See GNU or the Apollo program. > In the concrete case we're discussing here, only progressive tech companies signal their beliefs in this vulgar way, no conservative tech firm have ever put "Blue Lives Matter" or "Make America Gre…

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, and I don't know what to think about BLM), and alienating (the banner presupposes knowledge about BLM that most of the world doesn't have).

Re: A Kernel Hacker Meets Fuchsia OS

#260

Post by SubjectToChange »

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…

Android already isolates drivers from the linux kernel via binder IPC and HAL. Fuchsia is basically designed to operate in a similar way.
Post reply on HN