Re: [9fans] Undefined Behaviour in C

[Alexandru Gheorghe <alghe.global@gmail.com>]

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

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: 2826 bytes --]