linux-kernel - Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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