Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755279AbdDEAWb (ORCPT ); Tue, 4 Apr 2017 20:22:31 -0400 Received: from mail-io0-f193.google.com ([209.85.223.193]:34175 "EHLO mail-io0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752378AbdDEAW3 (ORCPT ); Tue, 4 Apr 2017 20:22:29 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170330194143.cbracica3w3ijrcx@codemonkey.org.uk> <20170331171724.nm22iqiellfsvj5z@codemonkey.org.uk> From: Linus Torvalds Date: Tue, 4 Apr 2017 17:22:27 -0700 X-Google-Sender-Auth: huVHkGwu2zAUMmUEir7wwXDZf6w Message-ID: Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! To: Kees Cook 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: 661 Lines: 20 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. Linus