Re: [9fans] Undefined Behaviour in C

[Brantley Coile <brantleycoile@me.com>]

[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]

Just curious, will Linux not panic when the kernel deterrences a nil pointer?

Sent from my iPad

> On Nov 25, 2015, at 5:27 AM, Alexandru Gheorghe <alghe.global@gmail.com> wrote:
> 
>> On 11/23/2015 01:20 PM, Vasudev Kamath wrote:
>> Ramakrishnan Muthukrishnan <ram@rkrishnan.org> writes:
>> 
>>> Had been reading the SOSP paper:
>>> <https://pdos.csail.mit.edu/papers/stack:sosp13.pdf>
>>> 
>>> and this blog post that proposes a simpler C:
>>> <http://blog.regehr.org/archives/1180>
>> I started reading the paper and its interesting. I didn't knew till date
>> how optimizations really worked and why they were considered harmful.
> 
> They can be quite harmful, the dereference example of tun->sk is a popular example that dates from 2009 regarding the Linux Kernel being exploited by Spender (Brad Spengler): https://lwn.net/Articles/342330/
> "a NULL pointer was dereferenced before being checked, the check was optimized out by the compiler, and the code used the NULL pointer in a way which allowed the attacker to take over the system"
> 
> Funny because Spengler did try many times to introduce better security in the Linux Kernel (see his set of patches in collaboration with the PaX Team: GRSEC) but was refused many times by the community and Linus in particular due to performance penalties (among other "opinions"). Which again opens the question where exactly is the undefined behavior problem? Resides on the programmer or on the compiler (and its programmers)? And how do you deal with the performance side? Because clearly, if you introduce more security then you will start having penalties on it; I guess the question is how much are you willing to let go in preference of more security and stable systems?
> 
> It's a very interesting paper, I only read 7 pages but will soon finish it and go ahead with the references (probably it links the example I wrote in the beginning of this e-mail).
> 
> Thanks for sharing.
> 
> -- 
> ; Alexandru Gheorghe
> ;
> ;       aGlobal
> ; <alghe.global gmail com>

[-- Attachment #2: Type: text/html, Size: 3167 bytes --]