Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXv5_h9nhKcd3_NYYnofOjorovm4NLbLuZoWzAbZKhM5uiEcg@mail.gmail.com>
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.