[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5jJHo4ogRfSaQvBEY0L-8NLCRvow8aHWcpW67XOBN97GDw@mail.gmail.com>
Date: Wed, 5 Apr 2017 12:39:17 -0700
From: Kees Cook <keescook@...omium.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Tommi Rantala <tommi.t.rantala@...ia.com>,
Dave Jones <davej@...emonkey.org.uk>,
Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Laura Abbott <labbott@...hat.com>,
Ingo Molnar <mingo@...nel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Eric Biggers <ebiggers@...gle.com>
Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!
On Tue, Apr 4, 2017 at 5:22 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Tue, Apr 4, 2017 at 3:55 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> I already explained what the likely fix is: make devmem_is_allowed()
>> return a ternary value, so that those things that *do* read the BIOS
>> area can just continue to do so, but they see zeroes for the parts
>> that the kernel has taken over.
>
> Actually, a simpler solution might be to
>
> (a) keep the binary value
>
> (b) remove the test for the low 1M
>
> (c) to avoid breakage, don't return _error_, but just always read zero
>
> that also removes (or at least makes it much more expensive) a signal
> of which pages are kernel allocated vs BIOS allocated.
This last part (reading zero) is what I'm poking at now. It's not
obvious to me yet how to make the mmap interface hand back zero-mapped
pages. I'll keep digging...
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists