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.glo...@gmail.com> > wrote: > >> On 11/23/2015 01:20 PM, Vasudev Kamath wrote: >> Ramakrishnan Muthukrishnan <r...@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>
