News for hackers. Stuff that matters.
Re:Escaping the Safari sandbox with a kernel GPU bug by alkonaut on Thursday November 27, 2014 @04:27AM (#8666560)
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 by gilgoomesh on Thursday November 27, 2014 @05:21AM (#8666680)
> 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 by pjmlp on Thursday November 27, 2014 @10:20AM (#8667550)
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.

Re:Escaping the Safari sandbox with a kernel GPU bug by illumen on Thursday November 27, 2014 @12:04PM (#8668041)
If Minix had used something else, then Linus probably/might have used that.
Re:Escaping the Safari sandbox with a kernel GPU bug by alkonaut on Thursday November 27, 2014 @10:58AM (#8667703)
The thing is; Rust could have been implemented long ago. It was triggered by Mozillas need for a parallell browser engine that is safe and doesn't crash all the time. One would have thought the same need would have existed for other code such as kernels and drivers for many years.
Re:Escaping the Safari sandbox with a kernel GPU bug by ajkjk on Thursday November 27, 2014 @03:22PM (#8668630)
This is my opinion as well. I know C is the only option right now. I'm amazed that we still find ourselves in that situation in 2014.
Re:Escaping the Safari sandbox with a kernel GPU bug by alkonaut on Friday November 28, 2014 @02:57AM (#8670050)
Also: C is the only option for parts of an OS. Writing it all in C because 10 or 25% needs it is a strange choice.
Re:Escaping the Safari sandbox with a kernel GPU bug by digi_owl on Thursday November 27, 2014 @07:23AM (#8666922)
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 by adrianN on Thursday November 27, 2014 @06:45AM (#8666829)
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 by digi_owl on Thursday November 27, 2014 @07:19AM (#8666912)
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 by pjmlp on Thursday November 27, 2014 @10:23AM (#8667565)
Ada is used in environments were human lifes are at risk life like life support systems, traffic control and so on.

From FOSDEM talks its use has been increasing thanks to C lack of safety, even with MISRA C.

Re:Escaping the Safari sandbox with a kernel GPU bug by digi_owl on Thursday November 27, 2014 @11:10AM (#8667763)
Yeah i guess that having the language enforce the rules makes for safer code than trying to impose safety externally.
Re:Escaping the Safari sandbox with a kernel GPU bug by pjmlp on Thursday November 27, 2014 @08:47AM (#8667234)
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 by alkonaut on Thursday November 27, 2014 @11:04AM (#8667734)
That's also a pet peeve of mine: the amalgamation of OS and compiler/language still feels like an odd design (of course, for me who arrived with time machine in the 2000's, so does teletypes and tape archives).