[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 17 Dec 2015 13:23:15 -0500
From: David Windsor <dave@...gbits.org>
To: kernel-hardening@...ts.openwall.com
Subject: Re: [RFC PATCH v2 01/12] x86: add PAX_REFCOUNT support
Well, pax_report_refcount_overflow is the mechanism for logging
overflows and for killing the offending process. Since that's related
to adding PAX_REFCOUNT protection (not necessarily to just x86,
though), I put it in this patch. I suppose I could have made another
patch for arch-independent changes like this.
You are correct that CONFIG_GRKERNSEC and CONFIG_PAX_REFCOUNT aren't
currently in the kernel, but they are both added in a later patch in
this series (patch 11/12). I should have made those changes part of
this patch, though. I will update the series and resubmit later.
Hopefully this answers your question?
Thanks,
David
On Thu, Dec 17, 2015 at 1:11 PM, Greg KH <greg@...ah.com> wrote:
> On Thu, Dec 17, 2015 at 12:55:44PM -0500, David Windsor wrote:
>> On Thu, Dec 17, 2015 at 12:16 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> > On Thu, Dec 17, 2015 at 09:57:39AM -0500, David Windsor wrote:
>> >> --- a/include/linux/sched.h
>> >> +++ b/include/linux/sched.h
>> >> @@ -749,6 +749,17 @@ struct signal_struct {
>> >> #ifdef CONFIG_TASKSTATS
>> >> struct taskstats *stats;
>> >> #endif
>> >> +
>> >> +#ifdef CONFIG_GRKERNSEC
>> >> + u32 curr_ip;
>> >> + u32 saved_ip;
>> >> + u32 gr_saddr;
>> >> + u32 gr_daddr;
>> >> + u16 gr_sport;
>> >> + u16 gr_dport;
>> >> + u8 used_accept:1;
>> >> +#endif
>> >> +
>> >
>> > Why is this here in this patch?
>> >
>>
>> For pax_report_refcount_overflow in fs/exec.c:
>>
>> 1754: if (current->signal->curr_ip)
>>
>> This is guarded by CONFIG_PAX_REFCOUNT, which, as it stands, should
>> depend on CONFIG_GRKERNSEC. The Kconfig options likely need to
>> change, depending on the naming of these features moving forward.
>
> But that has nothing to do with this patch, and as that config option
> isn't present in the kernel at this point in time, this change is not
> needed at all, right?
>
> Or am I missing something?
>
> thanks,
>
> greg k-h
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.
