[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXv5_g-VJJweZKNuw5ozMfiVxMrfhw4biEkSu4A29-uuEmD6A@mail.gmail.com>
Date: Mon, 16 Nov 2015 01:38:55 -0500
From: David Windsor <dave@...141.net>
To: kernel-hardening@...ts.openwall.com
Subject: Re:
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.
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).
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.
>
>
Content of type "text/html" skipped
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.
