Prevent list poison values from being mapped by userspace processes

[Kees Cook]

On Mon, Aug 24, 2015 at 12:32 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Aug 24, 2015 at 12:22:33PM -0700, Kees Cook wrote:
>> On Mon, Aug 24, 2015 at 12:14 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Mon, Aug 24, 2015 at 11:51:04AM -0700, Kees Cook wrote:
>> >> On Mon, Aug 24, 2015 at 11:47 AM, Russell King - ARM Linux
>> >> <linux at arm.linux.org.uk> wrote:
>> >> > That's something which Catalin indicated that he'll work on.  However,
>> >> > he said in a public email last week that he won't be around for a while.
>> >> >
>> >> > So, I have no immediate solution for LPAE - it looks like LPAE will
>> >> > require switching the page tables on kernel entry or exit, and again
>> >> > each and every time we want to perform a userspace access.  How this
>> >> > is done is not something that has been discussed, and neither do we
>> >> > yet know how expensive this will be.  There are a number of places in
>> >> > the kernel where a large number of get_user()s or put_user()s follow
>> >> > one after each other, which necessitates switching back and forth
>> >> > multiple times.  We may need to address some of those areas by
>> >> > converting them to copy_(to|from)_user().
>> >>
>> >> By the way, have you looked at grsecurity's implementation of these
>> >> protections? They've been using domains for a while now, and I think
>> >> have an LPAE solution as well.
>> >
>> > *Sigh*.
>> >
>> > No, and I really don't care - if people want to do development work out
>> > of the mainline kernel and not bother to talk about getting it upstream,
>> > it's their loss.  As far as I'm concerned, such external work doesn't
>> > exist.
>>
>> Sure, I understand, but it's worth at least looking at to compare
>> feature sets. For example, when doing the W^X kernel memory work, I
>> looked at both qcom and spender's work, trying to get the best of both
>> into upstreamable shape.
>
> That's one way of looking at it.
>
> Another way of looking at it is that by looking at their work, and
> merging their ideas into your own, it becomes an encouragement for
> working outside of mainline - not only do they get the kernel itself
> free, but they get their feature merged without themselves doing any
> work - while some other bugger has to sort out making their code
> mergable.
>
> Therefore, my standard point of view is that if people can't be
> bothered to talk about their ARM specific kernel features here with
> a view to having them merged, they are leeching off the efforts of
> the upstream kernel community, and their code just isn't worth
> looking at.
>
> I hold the same view on "community" kernel trees which don't bother
> pushing their code upstream as well.
>
> Sorry, I'm *not* supporting leeches.
>
> I've already been accused this year by one very mistaken individual
> for not pushing _my_ iMX6 work into community kernel trees - when
> the work that I do is solely targetted at mainline kernels.  The
> leeches are going mad, and I'm saying no more to this crap.  If it's
> not talked about on a recognised mainline kernel mailing list, it
> doesn't exist, and deserves to be rewritten.

I certainly see your point, but I'm not sure it serves end users best
to ignore proven technologies. I am trying to bring up the discussion
on a mainline list, and it seemed redundant to paste the entire grsec
forum post here as a starting point. :)

Anyway, I just want to see stuff as secure as possible. We're all
working toward the same goal.

-Kees

-- 
Kees Cook
Chrome OS Security