From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <83B8351E-61F9-4913-83B1-99ACC96381F4@me.com> References: <1448274004.1751482.447419065.2BE466C4@webmail.messagingengine.com> <87egfhotbl.fsf@copyninja.info> <56558D03.3040803@gmail.com> <83B8351E-61F9-4913-83B1-99ACC96381F4@me.com> Date: Wed, 25 Nov 2015 12:59:09 +0000 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114b30742e732f05255d0695 Subject: Re: [9fans] Undefined Behaviour in C Topicbox-Message-UUID: 773aaf08-ead9-11e9-9d60-3106f5b1d025 --001a114b30742e732f05255d0695 Content-Type: text/plain; charset=UTF-8 The link to the lwn.net article explains that using mmap the naughty application mapped a page to virtual 0, which was then available in kernel mode in that process, and all they'd need to do is put their own "socket" structure at 0 + offsetof(struct tun_struct, sk). On 25 November 2015 at 10:43, Brantley Coile wrote: > 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 > wrote: > > On 11/23/2015 01:20 PM, Vasudev Kamath wrote: > > Ramakrishnan Muthukrishnan writes: > > > Had been reading the SOSP paper: > > 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. > > > 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 > ; > > --001a114b30742e732f05255d0695 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The link to the lwn.net art= icle explains that using mmap the naughty application mapped a page to virt= ual 0, which was then available in kernel mode in that process, and all the= y'd need to do is put their own "socket" structure at 0 + off= setof(struct tun_struct, sk).

On 25 November 2015 at 10:43, Brantley Coile <brantle= ycoile@me.com> wrote:
Just curious, will Linux not panic when the kernel deterr= ences a nil pointer?

Sent from my iPad
<= div>
On Nov 25, 2015, at 5:27 AM, Alexandru Gheorghe <alghe.global@gmail.com>= wrote:

=20 =20 =20 =20 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 kn=
ew 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 que= stion 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.

--=20
; Alexandru Gheorghe
;
;       aGlobal
; <alghe.global gmail com>
=20

--001a114b30742e732f05255d0695--