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

121–130 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#121

Post by tester756 »

goodpoint wrote: post #107
native_samples wrote: post #87

Earlier quoted context omitted.

It's relevant because it reflects their priorities and how they view developers. The giant banners say this: although these are technical docs you may need to do your job, the most important thing you must see above all is an announcement of how morally pure we (think we) are. Once isn't enough. On our blog isn't enough. It must be the biggest and most eyecatching thing on literally every single page of our documenta…

> Steve Ballmer ... was ridiculed because the outburst of energy ... It was much, much worse than that. Putting aside the crass yelling and dancing; also putting aside any rumor of cocaine abuse; putting aside how cultish it looks... Having a large crowd of adults yelling "dentists! dentists!" or be it lawyers, accountants, etc in a frenzy would be seen as very unprofessional. > But many of us appreciated the sentime…

I think you're attacking weakest points of his comment, tbf.

Re: A Kernel Hacker Meets Fuchsia OS

#122

Post by erickt »

wittrock wrote: post #97
londons_explore wrote: post #93

Earlier quoted context omitted.

I like the idea of it being possible . Just because it's a feature doesn't mean you have to use it. For one thing, I assume such a system would have the ability to pin certain versions/hashes. If I (the user) can pin a set of hashes that are allowed to run, then I don't care where the actual resources are downloaded from. Alternatively, if I can give a certificate I trust of someone else to give a 'realtime' list, th…

Hi there, I work on Fuchsia, specifically on our Software Delivery system [1]. You hit on exactly the right point: it's _possible_ to download and run software on demand, but it's also possible (and recommended) for products to turn off that capability if it's not useful or valuable for their use case. We pin packages for the base system itself, as well as lots of configurations of products. The ability to run code o…

I also work on Fuchsia’s Software delivery team.

For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:

* a hardware key (on hardware that supports it), which checks the signature of

* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.

* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).

* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.

* base packages are then launched upon demand.

This establishes a direct line of trust from the hardware key to the base packages.

For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.

[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...

[2]: https://theupdateframework.io/

[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...

Re: A Kernel Hacker Meets Fuchsia OS

#123

Post by staticassertion »

turminal wrote: post #115
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…

> People say this about a lot of security things Unfortunately those people are often correct.

After that first ~dozen words I gave an example, a counter example, and discussed why this is a somewhat fundamental issue.

Re: A Kernel Hacker Meets Fuchsia OS

#124

Post by sydthrowaway »

kramerger wrote: post #28
qayxc wrote: post #20

Earlier quoted context omitted.

That would be too hard, it's a kernel that's actually developed with security in mind and is subject to active research (e.g. by DARPA).

If you try using sel4 in a project, you soon realise it is extremely limited and not at all useful for general purpose computers

In what way?

Re: A Kernel Hacker Meets Fuchsia OS

#125

Post by binkHN »

kernal wrote: post #117
binkHN wrote: post #2

Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished.

>Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished. Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.

You’re kidding right? Did you miss the parts about KASLR being broken and syscalls with TODOs for missing validations? And the CVEs created in relation to these?

Re: A Kernel Hacker Meets Fuchsia OS

#126

Post by staticassertion »

throwawaymaths wrote: post #64
why_only_15 wrote: post #40

Earlier quoted context omitted.

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…

In theory you could do even better than that -- you could make capabilities cryptographically signed tokens, so that you don't need to ask the kernel to verify the validity of your request every time. If your chipset supports crypto intrinsics this will almost certainly be better than an interrupted syscall.

Yeah, reminds me of biscuits[0] - because they're based on asymmetric cryptography they can be delegated, but also attenuated. If you just use a uuid that's not really going to work as well, unless you're willing to go back to some authority to forge a new, lesser capability.

Re: A Kernel Hacker Meets Fuchsia OS

#127

Post by skavi »

native_samples wrote: post #87
ignoramous wrote: post #53

Earlier quoted context omitted.

Just because they have those banners up doesn't mean those point to some latent reason for whatever is responsible for their woes. Granted it gives a window in to the culture of the Fuschia team at Google, but to me, personally, it doesn't come off as virtue-signalling at all but rather a conscious effort to put diversity and inclusion in the front and center of what they do. As another example, Google has had socio-…

It's relevant because it reflects their priorities and how they view developers. The giant banners say this: although these are technical docs you may need to do your job, the most important thing you must see above all is an announcement of how morally pure we (think we) are. Once isn't enough. On our blog isn't enough. It must be the biggest and most eyecatching thing on literally every single page of our documenta…

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 logic?

Re: A Kernel Hacker Meets Fuchsia OS

#128

Post by skavi »

jeltz wrote: post #111
ignoramous wrote: post #53

Earlier quoted context omitted.

Just because they have those banners up doesn't mean those point to some latent reason for whatever is responsible for their woes. Granted it gives a window in to the culture of the Fuschia team at Google, but to me, personally, it doesn't come off as virtue-signalling at all but rather a conscious effort to put diversity and inclusion in the front and center of what they do. As another example, Google has had socio-…

To me it comes off as inclusive of Americans while excluding the rest of the world. As a European I do not feel welcome, and I imagine people further from US culture feel even less welcome.

Would you mind going into why these banners make you feel unwelcome? Do you feel similarly about using the US Google homepage?

Re: A Kernel Hacker Meets Fuchsia OS

#129

Post by dhodell »

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.

Ironically, several folks who worked on Plan 9 later worked (or continue to work) at Google, although none of them worked on Fuchsia.

To me the major overlap between them is their designs are clearly informed by the contemporaneous shape of network architectures. Fuchsia is a take on what an OS design would be as a set of named microservices that can be routed. Plan 9 noticed network topologies of compute labs and clusters weren't too different, and both graphs could be represented in filesystems. The major visible difference to me is that the visibility of routing is much more apparent in Plan 9 than it is in Fuchsia. It's still a little difficult to understand how and where capabilities propagate through the system.

Implementation-wise, FIDL is a much different take than 9P2K. Though much simpler, 9P2K forces every API to exist via a filesystem interface (many of the higher level protocols also involve quite a lot of string passing) and struggles with throughput of streaming operations. Individual FIDL APIs might have similar problems, but the message encoding itself is relatively more efficient.

Re: A Kernel Hacker Meets Fuchsia OS

#130

Post by staticassertion »

binkHN wrote: post #125
kernal wrote: post #117

Earlier quoted context omitted.

>Very nice right up on how unfinished and insecure Fuchsia is as a result of it being so unfinished. Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.

You’re kidding right? Did you miss the parts about KASLR being broken and syscalls with TODOs for missing validations? And the CVEs created in relation to these?

KASLR is a pretty meh mitigation. But yeah, "todo" around capability checking probably should have been a higher priority fix.
Post reply on HN