Date: Mon, 16 Nov 2015 15:17:16 -0800 From: Kees Cook <keescook@...omium.org> To: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com> Subject: Re: On Sun, Nov 15, 2015 at 10:38 PM, David Windsor <dave@...141.net> wrote: > On Mon, Nov 16, 2015 at 12:45 AM, Daniel Micay <danielmicay@...il.com> > wrote: >> >> > I really can't see Linus and others being okay with any GCC >> > plugins with alterations to the semantics of C rather than just codegen >> > like the KERNEXEC plugin. >> >> Oh and REFCOUNT is basically the same situation. I can't see any >> possibility of that landing without switching to having a refcount_t >> type and having separate functions for working with it, with a >> configuration option like DEBUG_REFCOUNT to flip on overflow checks. >> It's a whole bunch of busy-work and since it will touch so much code it >> will run into the same problems that the previous attempts to upstream >> constification did. >> > I'm currently in the process of preparing my earlier PAX_REFCOUNT patch set > for resubmission, and I tend to agree with you - I'm not very hopeful of > Linus, et al accepting them. But, we will try again. When you've got it ready, let's review it here first. I've had a lot of experience navigating the upstreaming of unpopular things. :) We can bikeshed and test it on this list first, and then when we think it's ready, we can send it upstream. > With respect to the issue of having a refcount_t type, PAX_REFCOUNT adds > overflow protection to the already existing atomic_t type, and creates a new > type, atomic_unchecked_t, for non-reference-counter types (i.e. statistical > counters). I'm looking forward to testing this! I was pondering a quick and dirty LKDTM test to validate the results, too. Did you have anything already designed to test it? -Kees -- Kees Cook Chrome OS Security
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.