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

211–220 of 296 posts

Re: A Kernel Hacker Meets Fuchsia OS

#211

Post by ncmncm »

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

Code that has a preponderance of vtables is usually bad code written by Java transplants who haven't learned the right way to code C++. But that code has to run, too.

Re: A Kernel Hacker Meets Fuchsia OS

#212

Post by ncmncm »

fay59 wrote: post #198
DannyBee wrote: post #137

Earlier quoted context omitted.

Sure - but he also added the vulnerability he exploited in the first place?

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.

The code exploited was very, very far from any "best practice" in this decade, and probably the previous one.

Re: A Kernel Hacker Meets Fuchsia OS

#213

Post by ncmncm »

kardianos wrote: post #164
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 love so many ideas Fuchsia brings in. Blob storage as a primary FS type, software integrity, software archives that can naturally just pull blobs it requires from archives to name a few. A system that can as a first class, be atomically updated. I'm concerned that it may not get real use or that Google might poison the well it dug. But I would love to see it become a minimum viable desktop/embedded platform. But lo…

If it were not such bad code, it would seem more valuable.

Re: A Kernel Hacker Meets Fuchsia OS

#214

Post by IshKebab »

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.

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

Re: A Kernel Hacker Meets Fuchsia OS

#215

Post by corrral »

fartcannon wrote: post #209
corrral wrote: post #204

Earlier quoted context omitted.

> A couple? Yeah, I'm counting phones and tablets as two categories. But I'm also being really generous on how old something can be and still be "new" (15 years is quite a while, in tech) and not counting those as just an iteration (admittedly, a big one) on PalmOS devices and such. They're also much closer to being general-purpose devices than most other appliance-type machines (consoles, dedicated set-top boxes, et…

Phones and tablets are just locked down computers, not appliances. Do you want your laptop to be like that? Why not? Why is that any different than your tablet? Spoiler: It's not. 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…

Again: it is cheaper and easier than ever to get a "real" computer. They're at thrift stores for like $50-100, with peripherals. Raspberry Pi alone has sold over thirty million units. If a bright kid with a good idea asked for one on HN I bet a dozen people would ship their extras to them for free. Computers are given away for free pretty regularly on Craigslist and Facebook and such. Old but functional laptops can be had for tens of dollars on Ebay. It is wildly easier and cheaper to get into personal computing now than it was in the 80s, 90s, or even 00s. You can literally afford it by collecting loose change for a little while. A month of half-decent Internet service may well cost more than your entire computer set-up. This has been the consistent trend and it shows no sign of reversing, even after 15 years of iPhoneOS/iOS.

> the next Apple, only without the cruelty and greed.

Sigh. Well, never mind, I'm out.

Re: A Kernel Hacker Meets Fuchsia OS

#216

Post by josephcsible »

IshKebab wrote: post #214
josephcsible wrote: post #194

Earlier quoted context omitted.

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

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.

Re: A Kernel Hacker Meets Fuchsia OS

#217

Post by pjmlp »

ncmncm wrote: post #212
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.

The code exploited was very, very far from any "best practice" in this decade, and probably the previous one.

Unfortunately still a common reality across many corporations.

Re: A Kernel Hacker Meets Fuchsia OS

#218

Post by DannyBee »

fay59 wrote: post #198
DannyBee wrote: post #137

Earlier quoted context omitted.

Sure - but he also added the vulnerability he exploited in the first place?

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 equally automatic in most languages)

Re: A Kernel Hacker Meets Fuchsia OS

#219

Post by pjmlp »

zahllos wrote: post #106
giyanani wrote: post #49

Earlier quoted context omitted.

I’m not sure how fuschia does it, or how feature-based capabilities work, but Cheri[1] uses capabilities for memory management and isolation. It uses a couple of techniques, like wide/tagged pointers, object ids, and a special hardware managed bit to track illegal modifications. If I had to hazard a guess, those object ids are probably useful for general capability systems. I think apple (maybe as just an arm feature…

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

Re: A Kernel Hacker Meets Fuchsia OS

#220

Post by Rusky »

staticassertion wrote: post #210
Rusky wrote: post #200

Earlier quoted context omitted.

I'm specifically talking about Fuchsia and other kernel-based capabilities here. You fundamentally cannot print out that kind of capability in any way that matters- the only thing that determines whether a process has it is the table in the kernel, not whether it can produce a particular bit pattern. In this sense, fs APIs are a fine example, as long as you keep the ls/.. caveats in mind. If you have a file descripto…

I think the short version is that you're just not talking about capabilities.

How so? The line you quoted from Wikipedia calls them unforgeable. If you can forge it (by printing it out and reading it back in from somewhere else, or by guessing a bit pattern) then surely it's not a capability?
Post reply on HN