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

271–280 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#271

Post by zahllos »

saagarjha wrote: post #267
zahllos wrote: post #106

Earlier quoted context omitted.

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

PAC is ARMv8.3, and Apple implements their own custom algorithm rather than QARMA.

Yeah, ISA says you can. I wouldn't be surprised if other people pick other implementations, I'm not entirely sure why ARM felt the need for QARMA in the first place given there are already extensive choices for lightweight block ciphers, but... there you are.

Re: A Kernel Hacker Meets Fuchsia OS

#272

Post by cogman10 »

abdulla wrote: post #241
cogman10 wrote: post #229

Earlier quoted context omitted.

6 years of development and deployed to actual products is an experiment? 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 u…

Dart is core part of Flutter: https://flutter.dev What makes you say it's being killed?

Before it was a part of flutter it went through years of silence and effective death.

From roughly 2013->2015 the mailing list was practically silent on dart.

Even then, the language got "rebooted" with a v2 in 2018 to try and stir up some new life in a language everyone thought was dead.

Re: A Kernel Hacker Meets Fuchsia OS

#273

Post by Rusky »

staticassertion wrote: post #251
Rusky wrote: post #240

Earlier quoted context omitted.

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.

Then you've spent this entire thread arguing over clearly-explained terms of art, what a colossal waste of effort. I'm sorry to inform you: this is not how Fuchsia uses the word "capability."

Using your version of the word, since you appear incapable of operating in any other frame, Fuchsia does not use capabilities, and thus does not have the problem of leaking permissions via bit patterns. The original question of whether they need to be rotated periodically does not apply here.

Re: A Kernel Hacker Meets Fuchsia OS

#274

Post by Rusky »

throwaway894345 wrote: post #270
monocasa wrote: post #262

Earlier quoted context omitted.

In these non crypto enforced capability systems, you don't have any control over other processes' names for resources addressed through capabilities is the point I'm attempting to get across. Crypto backed capabilities that merge the token with the capability itself are one morph of capability based systems, but that's not the scheme being described here. Leaking the name of a capability (the offset in the cap table)…

Semantics aside, is it accurate to say that schemes where the capability is represented as a signed token require care and diligence to mitigate leaks, and schemes where the capability is represented as a table entry (mapping a user/process to a permission) don't require any meaningful care/diligence?

Yes, that's the idea.

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.

Re: A Kernel Hacker Meets Fuchsia OS

#275

Post by refulgentis »

dmitrygr wrote: post #246
refulgentis wrote: post #208

Earlier quoted context omitted.

So I have, this isn't true except in a facile way—"it felt to me like they would have left otherwise." It shipped, in an important way.

What way? As an update to the least important possible device, that all users hate since it “crashes daily now”? Big way indeed.

I very much doubt you work at Google, and if you do, shame on you. This is quite an evil comment, thread, and line of thought.

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

Re: A Kernel Hacker Meets Fuchsia OS

#276

Post by ErikCorry »

cogman10 wrote: post #229
tomComb wrote: post #227

Earlier quoted context omitted.

Yes, it may well be killed, but that’s Ok - it’s an experiment. But, yes, you need to take that into account before investing time in it. The other mistake that I think people make is assuming that because Google is a giant Corp. these things will move quickly, when in fact Google often puts small teams on non-critical projects.

6 years of development and deployed to actual products is an experiment? 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 u…

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

Well if it's any comfort that's not clear to the Googlers either.

On the other hand if something is done by a startup there's also no way to know how much of a future it has. At least if it's open source then you have time to migrate to something else if Google stops investing in it. All the examples you name are Open Source.

And I don't think it's accurate to say Google did a "soft kill" on Dart. I don't recall any time when they reduced the manpower on the project, excepting perhaps the Dartino/Fletch (embedded Dart), which was explicitly labelled as tentative and experimental. These days things are going great for Dart.

Re: A Kernel Hacker Meets Fuchsia OS

#277

Post by ece »

corrral wrote: post #157
fartcannon wrote: post #153

Earlier quoted context omitted.

You want to limit what current and future generations of people can do with their computers because of something a computer illiterate grandma may have done in the 90s? No. Those people get newspapers and landlines.

You badly overestimate both the ability and interest of average people in learning to administrate their computers. They just want to get shit done and go do something else. Computers are a tool at best, and more often a super-annoying thing they have to deal with but hate every second of it. If they actually like any of the computers around them, it's probably the most locked-down ones: their phones and video game c…

Consoles play games and media, off course people like them. Did the PS3 having the Other OS feature mean people enjoyed gaming on it less? I don't think so. Piracy as the given reason to take the feature away is a poor one, they could've better isolated the gaming partition. Apple designs their products to be more user friendly than most, it shouldn't stop users from doing what they want. They don't on the Mac, but they do on the iPhone.

Re: A Kernel Hacker Meets Fuchsia OS

#278

Post by ksec »

kllrnohj wrote: post #268
pjmlp wrote: post #245

Earlier quoted context omitted.

In countries where parents pay for kids computers, and worry about what everyone else is using, they don't get any uptakes. Before COVID, most schools were still about pen and paper in most European countries, computers are used at home.

That's yet again not true. Parents are often paying for the Chromebooks used in some of these markets (eg, US & Canada at least). That the school requires a certain OS doesn't change who pays for it, just like parents are still buying TI graphing calculators. > Before COVID, most schools were still about pen and paper in most European countries, Gonna need a citation on that one. It'd be quite surprising for European…

>It'd be quite surprising for European schools to be so far behind

Using Pen and Paper isn't so far behind, it is the wisdom to avoid hype.

Re: A Kernel Hacker Meets Fuchsia OS

#279

Post by staticassertion »

Rusky wrote: post #273
staticassertion wrote: post #251

Earlier quoted context omitted.

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.

Then you've spent this entire thread arguing over clearly-explained terms of art, what a colossal waste of effort. I'm sorry to inform you: this is not how Fuchsia uses the word "capability." Using your version of the word, since you appear incapable of operating in any other frame, Fuchsia does not use capabilities, and thus does not have the problem of leaking permissions via bit patterns. The original question of…

There's really no debate here. I'm right. A capability is defined as I have defined it. You can say "well Fuschia says otherwise", that's fine, people are wrong about things all the time. Such is life.

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.

Re: A Kernel Hacker Meets Fuchsia OS

#280

Post by bumblebritches5 »

josephcsible wrote: post #194
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.

No post body was provided.
Post reply on HN