Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933455AbdDETjX (ORCPT ); Wed, 5 Apr 2017 15:39:23 -0400 Received: from mail-io0-f179.google.com ([209.85.223.179]:36772 "EHLO mail-io0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751881AbdDETjS (ORCPT ); Wed, 5 Apr 2017 15:39:18 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170330194143.cbracica3w3ijrcx@codemonkey.org.uk> <20170331171724.nm22iqiellfsvj5z@codemonkey.org.uk> From: Kees Cook Date: Wed, 5 Apr 2017 12:39:17 -0700 X-Google-Sender-Auth: oDhRVOxE771nVw6BRukPlEfMCLw Message-ID: Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! To: Linus Torvalds Cc: Tommi Rantala , Dave Jones , Linux-MM , LKML , Laura Abbott , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Eric Biggers Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 954 Lines: 30 On Tue, Apr 4, 2017 at 5:22 PM, Linus Torvalds wrote: > On Tue, Apr 4, 2017 at 3:55 PM, Linus Torvalds > 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