From mboxrd@z Thu Jan 1 00:00:00 1970 Content-type: multipart/alternative; boundary=Apple-Mail-0BE400EA-4E4E-4BB2-AF6F-2009174C7F77 MIME-version: 1.0 (1.0) From: Brantley Coile In-reply-to: <56558D03.3040803@gmail.com> Date: Wed, 25 Nov 2015 05:43:23 -0500 Content-transfer-encoding: 7bit Message-id: <83B8351E-61F9-4913-83B1-99ACC96381F4@me.com> References: <1448274004.1751482.447419065.2BE466C4@webmail.messagingengine.com> <87egfhotbl.fsf@copyninja.info> <56558D03.3040803@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Undefined Behaviour in C Topicbox-Message-UUID: 77319fee-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-0BE400EA-4E4E-4BB2-AF6F-2009174C7F77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 w= rote: >=20 >> On 11/23/2015 01:20 PM, Vasudev Kamath wrote: >> Ramakrishnan Muthukrishnan writes: >>=20 >>> Had been reading the SOSP paper: >>> >>>=20 >>> and this blog post that proposes a simpler C: >>> >> I started reading the paper and its interesting. I didn't knew till date >> how optimizations really worked and why they were considered harmful. >=20 > 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 S= pender (Brad Spengler): https://lwn.net/Articles/342330/ > "a NULL pointer was dereferenced before being checked, the check was optim= ized out by the compiler, and the code used the NULL pointer in a way which a= llowed the attacker to take over the system" >=20 > Funny because Spengler did try many times to introduce better security in t= he Linux Kernel (see his set of patches in collaboration with the PaX Team: G= RSEC) but was refused many times by the community and Linus in particular du= e to performance penalties (among other "opinions"). Which again opens the q= uestion where exactly is the undefined behavior problem? Resides on the prog= rammer or on the compiler (and its programmers)? And how do you deal with th= e 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? >=20 > 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 t= he beginning of this e-mail). >=20 > Thanks for sharing. >=20 > --=20 > ; Alexandru Gheorghe > ; > ; aGlobal > ; --Apple-Mail-0BE400EA-4E4E-4BB2-AF6F-2009174C7F77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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>
--Apple-Mail-0BE400EA-4E4E-4BB2-AF6F-2009174C7F77--