Live data from Hacker News

Why is it all in the kernel?

lawrencecpaulson.github.io

31–40 of 43 posts

Re: Why is it all in the kernel?

#31
post #29
post #17

Earlier quoted context omitted.

The one thing that gives me concern in their is "nanoda [the external proof checker] is [now] tracked daily". Although that would have caught this issue, we also now live in a world in which some model is going to think that hacking the proof-checker distribution is the obvious way to obtain the proof it is after; I expect that attempts on that will be much more common than soundness bugs. However, this is said witho…

This used to be the bane of all machine learning experiments. It might have been lost to time but I once stumbled upon a big list of AI reward-hacks like this. Things like - we tried to develop fast cars, but the AI just made a really tall weighted stick that would fall over onto the finish line. And we tried to teach the AI not to lose in Tetris, so it hit pause whenever it was about to.

It's called reward hacking

https://en.wikipedia.org/wiki/Reward_hacking

Re: Why is it all in the kernel?

#32
post #26
post #23

Earlier quoted context omitted.

It doesn't, it just loses your session

A kernel panic doesn't bring down the CPU, nor the hard drive, or the RAM, or the power supply unit. So if we're being pedantic, the machine is still up.

Well, a kernel bug gets write access to everything. A bug in userland is a bit more constrained in what it can do.

That counts especially for accidental bugs and denial of service. To make a userland bug exploited adversarially not impact the rest of the system requires more hardening of the kernel.

Re: Why is it all in the kernel?

#33
post #32
post #26

Earlier quoted context omitted.

A kernel panic doesn't bring down the CPU, nor the hard drive, or the RAM, or the power supply unit. So if we're being pedantic, the machine is still up.

Well, a kernel bug gets write access to everything. A bug in userland is a bit more constrained in what it can do. That counts especially for accidental bugs and denial of service. To make a userland bug exploited adversarially not impact the rest of the system requires more hardening of the kernel.

Yeah a userland bug just gets all my passwords, SSH keys, personal secrets and whatever.

Say it with me - there's no practical difference.

Re: Why is it all in the kernel?

#34
post #33
post #32

Earlier quoted context omitted.

Well, a kernel bug gets write access to everything. A bug in userland is a bit more constrained in what it can do. That counts especially for accidental bugs and denial of service. To make a userland bug exploited adversarially not impact the rest of the system requires more hardening of the kernel.

Yeah a userland bug just gets all my passwords, SSH keys, personal secrets and whatever. Say it with me - there's no practical difference.

You are talking about a single user system.

You can compartmentalise further.

Modern processors even give you these 'rings' to help with the hardware side of that, if you want to.

Re: Why is it all in the kernel?

#36
post #34
post #33

Earlier quoted context omitted.

Yeah a userland bug just gets all my passwords, SSH keys, personal secrets and whatever. Say it with me - there's no practical difference.

You are talking about a single user system. You can compartmentalise further. Modern processors even give you these 'rings' to help with the hardware side of that, if you want to.

Yes, these are the standard excuses. But has anyone actually thought about them in the last twenty years, in the context of the way we actually use computers?

Re: Why is it all in the kernel?

#37

Proof assistant kernel, not operating system kernel - in case, like me, you clicked in hoping to debate the merits of microkernels vs monolithic:) Although I suppose there is a significant analogy, since the argument here... if I understood right... is very close to the classic 'and now a small defect in a device driver just panicked the system or gave an attacker root', just in math terms.

Hey, it's been awhile since we had a good microkernels vs monolithic debate. Time to post it!

Re: Why is it all in the kernel?

#38
post #36
post #34

Earlier quoted context omitted.

You are talking about a single user system. You can compartmentalise further. Modern processors even give you these 'rings' to help with the hardware side of that, if you want to.

Yes, these are the standard excuses. But has anyone actually thought about them in the last twenty years, in the context of the way we actually use computers?

Eh, yes? Just look the discussions surrounding the development of any web browser? Or look at the permissions system in Android or iOS or on Mac (and perhaps even Windows?).

Re: Why is it all in the kernel?

#39
post #38
post #36

Earlier quoted context omitted.

Yes, these are the standard excuses. But has anyone actually thought about them in the last twenty years, in the context of the way we actually use computers?

Eh, yes? Just look the discussions surrounding the development of any web browser? Or look at the permissions system in Android or iOS or on Mac (and perhaps even Windows?).

So you acknowledge a browser bug is just as bad as a kernel bug.

Re: Why is it all in the kernel?

#40
post #29
post #17

Earlier quoted context omitted.

The one thing that gives me concern in their is "nanoda [the external proof checker] is [now] tracked daily". Although that would have caught this issue, we also now live in a world in which some model is going to think that hacking the proof-checker distribution is the obvious way to obtain the proof it is after; I expect that attempts on that will be much more common than soundness bugs. However, this is said witho…

This used to be the bane of all machine learning experiments. It might have been lost to time but I once stumbled upon a big list of AI reward-hacks like this. Things like - we tried to develop fast cars, but the AI just made a really tall weighted stick that would fall over onto the finish line. And we tried to teach the AI not to lose in Tetris, so it hit pause whenever it was about to.

Was it this one? https://docs.google.com/spreadsheets/d/e/2PACX-1vRPiprOaC3Hs...
Post reply on HN