Great article! ... I'm glad I already disable hardware acceleration having hit kernel panics there on OS X before. (I did a write up, http://www.brendangregg.com/blog/2014-05-23/osx-10.9.3-is-to..., but it's much less interesting/useful than this blog post).
Escaping the Safari sandbox with a kernel GPU bug
11–20 of 31 posts
Re: Escaping the Safari sandbox with a kernel GPU bug
#12I always feel a bit strange around security and exploitation people. Security is important, but it's so much easier to destroy and criticize stuff than to build something useful and try to balance all the aspects of a product.
Re: Escaping the Safari sandbox with a kernel GPU bug
#13This writeup, and the first part of this series, are amazing and incredibly instructive. But they make me embarrassed that anyone still runs or writes code that is so without memory safety that these bugs can exist.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in tools preventing stupid low-level bugs, we likely end up creating new high level bugs that were squashed years ago in the old C code. Still, isn't this something that has to be done?
Re: Escaping the Safari sandbox with a kernel GPU bug
#14This writeup, and the first part of this series, are amazing and incredibly instructive. But they make me embarrassed that anyone still runs or writes code that is so without memory safety that these bugs can exist.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in…
> We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems
Not for kernel development we don't.
The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development.
And even a safe language like Rust won't prevent escalation problems like this if you're placing too much trust in incoming data. That's a design problem that has nothing to do with languages or memory safety.
Re: Escaping the Safari sandbox with a kernel GPU bug
#15"And if you're still running OS X Mavericks or below then why not try it out?"
In other words: "insecure" or "unstable" - choose one.
I'm all for upgrading to Yosemite, but this is a problem.
Re: Escaping the Safari sandbox with a kernel GPU bug
#16Earlier quoted context omitted.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in…
> We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems Not for kernel development we don't. The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development. And even a safe language like Rust won't prevent escalation problems like this if you…
Ada is a modern language that allows for very low level code and is about as fast as C.
Re: Escaping the Safari sandbox with a kernel GPU bug
#17Earlier quoted context omitted.
> We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems Not for kernel development we don't. The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development. And even a safe language like Rust won't prevent escalation problems like this if you…
Ada is a modern language that allows for very low level code and is about as fast as C.
Thats what the US military use on mission critical systems, right? Seem to recall reading that it is a pain to work with.
Re: Escaping the Safari sandbox with a kernel GPU bug
#18Earlier quoted context omitted.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in…
> We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems Not for kernel development we don't. The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development. And even a safe language like Rust won't prevent escalation problems like this if you…
Rust looks sexy. And i think Mozilla is using it to implement an alternative render/JS engine or something.
Re: Escaping the Safari sandbox with a kernel GPU bug
#19This writeup, and the first part of this series, are amazing and incredibly instructive. But they make me embarrassed that anyone still runs or writes code that is so without memory safety that these bugs can exist.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in…
Because UNIX was embraced by the enterprise and brought C along.
Algol 68, Modula-2, Mesa, Cedar were all options back when UNIX was being brought to life.
Re: Escaping the Safari sandbox with a kernel GPU bug
#20Earlier quoted context omitted.
The idea of passing around function pointers like raw values that way, or having a language+runtime without array bounds checks or checks for dereferencing invalid pointers is just frightening. We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems. So why not start rebuilding low level systems using better tools? Granted, if we rewrite kernels, drivers, encryption etc in…
> We have tools now such that if they had been around in the 60's/70's we wouldn't have these problems Not for kernel development we don't. The only modern, memory-safe language that gets close(-ish) to the performance of C for kernel development is Rust and it's a long way from being stable enough for mainstream kernel development. And even a safe language like Rust won't prevent escalation problems like this if you…
Yes we have. Xerox PARC systems were mainly developed in Mesa after some bootstrap work in BCPL.
ETHZ OS were done in Modula-2, Oberon, Active Oberon.
Olivetti and DEC were using Modula-3.
Several OS were being done in Algol and PL/I dialects back when UNIX was being born.
C's ubiquity is a consequence of UNIX adoption by some successful startups in the workstation market.
If one of the other systems had enjoyed a similar adoption another safer systems programming language would have taken C's adoption.