A Kernel Hacker Meets Fuchsia OS • Hacker News Board

Re: A Kernel Hacker Meets Fuchsia OS

#221

Post by pjmlp » Wed, May 25, 2022, 10:00 PM UTC

ncmncm wrote: post #211

jcranmer wrote: post #205

Something that I haven't seen brought up yet is the "weird C++ vtable layout." This is actually the "relative vtable layout" that's first described here: https://bugs.llvm.org/show_bug.cgi?id=26723 , and is usable in clang via the -fexperimental-relative-c++-abi-vtables option. The basic idea is that you don't need to waste a whole 64 bits for vtable entry, especially since you can usually assume that code within the…

Space for vtables is almost always negligible, especially so on 64-bit targets. So the main effect of inflated vtables is cache footprint. But where that matters most, you probably shouldn't be doing virtual calls anyway. Compilers don't get to say what you compile. People care about the speed of bad code almost as much as good code, and sometimes more: what bad code wastes, the compiler might be able to give some of…

Before Java came into the world I remember Turbo Vision, Powerplant, CSet++, OWL, MFC, Motif++, VCL, Tools.h++,...

Re: A Kernel Hacker Meets Fuchsia OS

#222

Post by pjmlp » Wed, May 25, 2022, 10:02 PM UTC

josephcsible wrote: post #216

IshKebab wrote: post #214

Earlier quoted context omitted.

Nonsense. Linux already doesn't require hardware vendors to provide driver sources. Fuchsia just makes it easier to upgrade things when they don't.

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

Re: A Kernel Hacker Meets Fuchsia OS

#223

Post by pjmlp » Wed, May 25, 2022, 10:07 PM UTC

kllrnohj wrote: post #141

native_samples wrote: post #68

Earlier quoted context omitted.

Yes. Android is sufficiently different from a stock Linux distro that it absolutely counts as a unique operating system. ChromeOS is also unique in interesting ways, although less successful. It's certainly a production quality OS. Perhaps more importantly, both of those are complete and have real users who found value in them.

> ChromeOS is also unique in interesting ways, although less successful. 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.

That is an US phenomenon though.

It can be hardly seen in European countries, and I bet other continents are hardly different.

Re: A Kernel Hacker Meets Fuchsia OS

#224

Post by fay59 » Wed, May 25, 2022, 10:12 PM UTC

DannyBee wrote: post #218

fay59 wrote: post #198

Earlier quoted context omitted.

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.

Sure - look i'm not gonna argue about C++ memory safety - i've funded and spent time trying to ensure we are funding figuring out how to get off of C++. I just assume C++ code is unsafe, because it's really really hard to make it safe. However, at the same time, the privilege escalation issues would have happened in any language - if you don't implement the check, you don't implement the check. (and you could make it…

What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel instead. I don’t mean that you can’t write bugs in memory-safe languages, but in the end the attacker still has to play by your rules. With a memory safety bug, attackers play by no one’s rules.

Re: A Kernel Hacker Meets Fuchsia OS

#225

Post by josephcsible » Wed, May 25, 2022, 10:14 PM UTC

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.

So just because some people have broken rules and gotten away with it so far, we should get rid of those rules for everyone?

Re: A Kernel Hacker Meets Fuchsia OS

#226

Post by zahllos » Wed, May 25, 2022, 10:15 PM UTC

pjmlp wrote: post #219

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…

Apple isn't the only one, Oracle did it first with SPARC ADI on Solaris.

True. I was mainly responding to the ARM encrypted pointers part with that bit. ARM also didn't invent memory tagging, which might also have come from SPARC ADI (I'm not sure), but they also plan to include that. QARMA itself looks to be designed by Qualcomm engineers: https://eprint.iacr.org/2016/444.pdf

A lot of good stuff has come from SPARC :)

Re: A Kernel Hacker Meets Fuchsia OS

#227

Post by tomComb » Wed, May 25, 2022, 10:18 PM UTC

michaelbrave wrote: post #166

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 just don't trust google to not abandon it like it has most other things they made that I invested in. It's brand erosion same as what's happened with Blizzard, used to have a lot of trust, lots of disappointments later and now I go in skeptical. Personally I think Fuchsia is cool, and there is a lot to like, but I expect to hear it was killed by google anyday now.

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.

Re: A Kernel Hacker Meets Fuchsia OS

#228

Post by pjmlp » Wed, May 25, 2022, 10:18 PM UTC

josephcsible wrote: post #225

pjmlp wrote: post #222

Earlier quoted context omitted.

It is sooo successful on the Android, IoT ecosystems.

So just because some people have broken rules and gotten away with it so far, we should get rid of those rules for everyone?

Rules that can be broken in the open without consequences aren't rules.

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.

Re: A Kernel Hacker Meets Fuchsia OS

#229

Post by cogman10 » Wed, May 25, 2022, 10:29 PM UTC

tomComb wrote: post #227

michaelbrave wrote: post #166

Earlier quoted context omitted.

I just don't trust google to not abandon it like it has most other things they made that I invested in. It's brand erosion same as what's happened with Blizzard, used to have a lot of trust, lots of disappointments later and now I go in skeptical. Personally I think Fuchsia is cool, and there is a lot to like, but I expect to hear it was killed by google anyday now.

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 updates slow or stop and the mailing list stops getting responses.

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

Re: A Kernel Hacker Meets Fuchsia OS

#230

Post by cogman10 » Wed, May 25, 2022, 10:34 PM UTC

josephcsible wrote: post #225

pjmlp wrote: post #222

Earlier quoted context omitted.

It is sooo successful on the Android, IoT ecosystems.

So just because some people have broken rules and gotten away with it so far, we should get rid of those rules for everyone?

Nobody has broken rules. The rules are simply permissive enough that you can still push out a Non-GPL drivers for a GPL mono-kernel.

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.