Did you even read the write up? The only bug found was the ability to read the kernel log. Everything else was manufactured.

I don’t see them re-enabling it later, so yes, they found security problems, but they didn’t show a complete attack, either.

You start with something secure and rudimentary and add features over time.

You don't start with something unsecure and then add security to it.

(yes... it's also a very limited OS... maybe someday it gets a decent GUI and starts to get more attention)

On the one hand POSIX et al is effectively impossible to deploy in a secure way, so there is a reasonable argument for going back to the drawing board; but on the other hand there isn't really a well-defined go-to alternative How To Computer model that is friendly to provable security, so everyone has gets to reinvent that wheel every time

Considering the contemporary status quo in terms of independently-implemented OS projects and platforms (eg, my ever-so-slightly-wobbly VxWorks-based TP-LINK consumer ADSL modem), I do wonder how good seL4 implementations end up working out in practice - the kernel might be rock solid, but what about all the bits on top of it, some of which presumably communicate with the outside world, consume various protocols, need to control the hardware in various ways (which includes relying upon reading the hardware state/status), etc?

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

None of what you're saying is true, you've gone for extreme hyperbole in every comment you've made, from Fuchsia being a "retention project", to the Nest Hub being the "least important device" to "all users hate it" "it crashes daily now."

Anyways, if you’re going to build an alternative or fork another stack —- you might as well hit two birds with one stone. Fuchsia’s relatively distinct capability-based, quasi-microkernel (it is not in fact a microkernel on a strict read) architecture is a chance to cleave off technical debt and start anew on security, and it’s relative modularity dovetails into the whole driver, kernel interface issue.

>This is a known-issue. KASLR support on the zircon kernel is just there so that it doesn't bit-rot. We are always picking up a static address instead of a dynamic one.

>Once physboot rollout is complete, that should make it easier to support kaslr.

But those write-ups were years ago and there hasn't been new reviews with much UI focus since then.

I'm doubtful many people would be able to read it or contribute to it very effectively.

Yes they do; they run code written by Google. The only thing worse would be Facebook; the literal NSA are more trustworthy.

I guess I was thinking more Laptops and Phones.

Chrome OS absolutely dominates the education market. So less successful than Android, sure (but so is literally every other OS at this point), but still very successful.

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

Yay for arguable freedom.

Yes it does. The GPL literally does exactly that.

The issue I have with Google is it's never clear to outsiders when projects are simply "experiments" that google is going to kill later. Dart, GWT, Angular Dart, for example, seemed like more than "experiments" yet google did a soft kill on Dart and effectively a hard kill on GWT.

You learn that something is "an experiment" when all the sudden updates slow or stop and the mailing list stops getting responses.

I don't trust google software because google bureaucracy is fickle and unpredictable.

That didn't go away because people learned. And it never would have.

The Fuchsia design is good because it recognizes that reality and creates a world where patching the kernel doesn't require hardware vendors to rebuild their drivers.

In any case, the transition to MIT based FOSS on embedded platforms like Zephyr, RTOS, NutX,... proves that it won't matter for much longer anyway.

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 documentation. This indicates a lack of respect for the time and attention of devs. The implementation is also incompetent - the banner text appears to have leaked into search result snippets, thus reducing the utility of their docs search engine.

When Steve Ballmer jumped around on stage yelling "developers! developers! developers!" he was ridiculed because the outburst of energy seemed absurd and out of place for a CEO. But many of us appreciated the sentiment - that if you're developing an operating system then developers matter and their time/attention matters. Ballmer knew that. Platforms aren't chicken/egg situations where it's unclear what comes first. Apps come first. Users come for the apps. Then more apps come to follow those early adopter users, but ultimately, there had to be some apps to kick things off.

When the first thing you see at the top of the Fuschia docs is something totally unrelated to programming / the reason you were at that site, and which is irrelevant to most of the world as well, this sends a powerful message that the Fuschia devs are:

a. Staggeringly US centric. Their mindset isn't international at all. This is offputting to those of us outside the US. Fuschia's front page claims it's "an inclusive, open source effort". Not only have they never even tested it with a non-English locale, but they ignored the critical locale bug for so long other people had to fork the project to even make the emulator start up for non-English users [1]. That's about as non-inclusive as you can get yet is also absolutely predictable. Did we really need the blog to tell us that? Not really, we could guess it quite easily. The sort of people who demand such banners always seem to be hypocrites. It's called virtue signalling for a reason - people who do it announce their principles but never seem to live by them.

b. Not really rewarded for making developers happy. It reinforces a general impression about modern Google, that the personal success of the employees and executives is tied to things like the size of a giant black banner as much as whether their kernel is secure or their API docs are actually accurate.

c. As such extremely likely to manipulate their platform to prioritize the happiness of activists over that of developers. It's a bold statement of ideological allegiance. Who in their right mind is going to write an app for Fuschia that's braver than a shopping cart when they see that? Nobody smart, because you can guess what will happen if Fuschia actually does get apps: half of them will end up banned for some inane, impossible to understand reason, probably related to mundane use of language that's inexplicably become unacceptable since yesterday in California. The financial risk of developing for this platform is huge.

BTW: the Google doodles are pretty political these days, but in the beginning they were mostly reflecting things like national holidays.

[1] https://github.com/assusdan/fuchsia-patches

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

Before COVID, most schools were still about pen and paper in most European countries, computers are used at home.

In my comment I meant "in theory fuscia could have been architected/could be rearchitected that way", sorry should have been more clear.

If yes, man that's really dangerous thinking.

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?

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.

That's precisely how it works in FreeBSD (https://www.freebsd.org/cgi/man.cgi?capsicum).

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.

Some people only have access to tablets and phones. Let them have the freedom we had to create something. With that freedom, maybe one of them grows up and creates the next Apple, only without the cruelty and greed.

On top of that, it would reduce waste.

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

Politics and religion are notoriously related. They are both morally charged subjects that infamously degrade people's ability to see the world clearly and discuss pros and cons rationally. I can cite plenty of pro-BLM speech and actions that disturbingly mirror religious language and actions. The fact that most BLM supporters might not speak or act like this is irrelevant too, most Christians don't go to church either.

>The former mixes, often by necessity, with technical documents all the time. See GNU or the Apollo program.

I'm really puzzled as to how this supports BLM banners in OS design documents though. You said "by necessity", is BLM mottos and iconography necessary to understand micro kernels as much as Cold War terms and timeline is necessary to understand the Apollo program ? that would be an... interesting point to argue.

Even ignoring this, not all politics is created equal. "The Apollo program was created as a demonstration of technical supramecy by the US intended to intimidate the USSR" is politics. "The Apollo program was when we showed those dirty commies who's the boss" is also politics. I hope you agree the first statment is vastly more palatable and neutral than the second. The vast majority of progressive mottos and rallying cries strike my ears like the second statment.

>No, but many will willingly participate in the US military industrial complex, which causes significantly more actual harm.

This is a strange thing to say for more reasons than 1

1- Conservative tech companies aren't any more likely to cooperate with the US military than progressive tech companies. Amazon and Google, hardly bastions of conservatism, are both known contractors to the US military. So if you hate this, you should hate all influential US tech companies, conservatism is not a useful predictor of this any more than random chance.

2- I'm not assessing who is "doing more harm overall", I'm assessing who's asserting ideological power over people in vulgar ways. US military power projection is an entirely different topic for a different conversation, we're now talking about who brings their obnoxious politics into the workplace. There are different ways of disliking things, I dislike the US military power posturing and US progressives power posturing in 2 different ways.

>This kind of banner is uncommon even among Silicon Valley companies.

Which is all the more reason to think it's forced virtue signaling.

>It’s not as if there would be outrage if it weren’t there, or if it disappeared.

I see you're unfamiliar with Twitter.

>Finally, these are all reasons why someone who doesn’t agree with BLM would feel excluded by the banner.

When it comes to religions and religion-like things, "disagree" is anything that isn't "agree". Any Non-Muslim "disagrees" with Islam, not because they have read the history of the prophet (which is awful) or studied Islamic Theology's arguments for why Islam is true (which is weak), but simply because Non-Muslims don't say "No God but Allah" and don't pray 5 times a day. They are non-believers, not dis-believers.

>Do you feel that most people outside of the US view BLM negatively or indeed have an opinion at all?

I can't speak for all the world off course, but I do feel that BLM is entirely irrelevant and unknown in my country, even if the events that sparked and galvanized it was internationally known. Again, no need for intense, explicit disagreement here, although I personally do think it's a destructive obvious scam\religion mix that every person who knows what it does and what kind of people run it should oppose it intensely, but there's really no reason to go that far.

Do you think you need hate or disagree with Islam to despise and hate the hypothetical practice of Muslims writing religious verses in completely unrelated writings? Do you think you need to hate or disagree with Communism to despise the hypothetical practice of Chinese Scientists writing pro-CCP mottos in completely unrelated writings?

My answer to the above question is No, I hate ideological spamming as a pathetic authoritarian practice regardless of the ideology doing it. In fact, sometimes I will hate the ideology itself, for no other reasons but the spam that its fanatics continually pump, and I think my view is a fairly popular and widespread to view things.

Whatever merits BLM might have had, it's completely eclipsed by the fact that their true believers seem to believe that micro kernel developers must hear them when they are reading up on their work.

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.

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. Further up above you're also conflating files and file descriptors, which are very different things.

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 pattern somehow. Trick someone into printing it out, read it out of their memory space, leak it via a side channel, attack their UUID generator, etc. For this kind of capability, sure- periodic revocation might be a worthwhile mitigation technique.

But for "trusted state" capabilities, which is where this thread started, and what file descriptors exemplify, this all goes away. The attack surface is reduced to the kernel and the component's own API (nothing new here) and its use of a finite set of capability delegation APIs. Leaking an fd number does not leak the corresponding capability the way leaking a Dropbox URL does, so there is relatively little purpose in rotating those out.

Of course I've spent this entire thread explaining a clearly defined term, was that not obvious?

And yes, rotation is relevant to capabilities because leaking capabilities is a critical failure. It's not the only way to protect capabilities though, you can add ACLs or namespaces, which is what Fuschia seems to do.

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

Though, it is still worth thinking about how someone might accidentally leak a table-based capability via API misuse. For example, if table entries are reused over time you might get a sort of use-after-free situation where you mean to share an old capability but accidentally share the new one that replaced it.