From mboxrd@z Thu Jan 1 00:00:00 1970 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Brantley Coile In-reply-to: Date: Wed, 25 Nov 2015 09:25:55 -0500 Content-transfer-encoding: quoted-printable Message-id: References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Undefined Behaviour in C Topicbox-Message-UUID: 7743ff5e-ead9-11e9-9d60-3106f5b1d025 Insert various complaints about unwise complexities and their unindented = consequences here.=20 Just my personal taste, but I didn=E2=80=99t like shared libraries when = the Unix world in the 1980=E2=80=99s were copying Window=E2=80=99s DLLs, = and could never see the reason for linking the file system and paging = system. Most thought it was neat that one could leverage the paging code = to just mmap a file into their address space and just read it. At the = time Dennis observed that storage was still larger than the address = space of machines. This didn=E2=80=99t dissuade people to do that = anyway, forever making the file system block size linked to the paging = system on Unix-like systems. Interesting that it is still causing problems. Of course Plan 9 has neither shared libraries nor mmap. That=E2=80=99s a = good thing. > On Nov 25, 2015, at 8:48 AM, erik quanstrom = wrote: >=20 > so to answer bwc's question, no. not always.=20 >=20 > On Nov 25, 2015 4:59 AM, Charles Forsyth = wrote: > 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). >=20 > On 25 November 2015 at 10:43, Brantley Coile = wrote: > Just curious, will Linux not panic when the kernel deterrences a nil = pointer? >=20 > Sent from my iPad >=20 > On Nov 25, 2015, at 5:27 AM, Alexandru Gheorghe = wrote: >=20 > On 11/23/2015 01:20 PM, Vasudev Kamath wrote: > Ramakrishnan Muthukrishnan > writes: >=20 >=20 > Had been reading the SOSP paper: >=20 > >=20 >=20 > and this blog post that proposes a simpler C: >=20 > > 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 >=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 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" >=20 > 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? >=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 the beginning of this e-mail). >=20 > Thanks for sharing. >=20 > --=20 > ; Alexandru Gheorghe > ; > ; aGlobal > ; >=20 >=20