Insert various complaints about unwise complexities and their unindented consequences here.
Just my personal taste, but I didn’t like shared libraries when the Unix world in the 1980’s were copying Window’s 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’t 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’s a good thing. > On Nov 25, 2015, at 8:48 AM, erik quanstrom <quans...@quanstro.net> wrote: > > so to answer bwc's question, no. not always. > > On Nov 25, 2015 4:59 AM, Charles Forsyth <charles.fors...@gmail.com> 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). > > On 25 November 2015 at 10:43, Brantley Coile <brantleyco...@me.com> 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 <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> > >
