From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f70.google.com (mail-it0-f70.google.com [209.85.214.70]) by kanga.kvack.org (Postfix) with ESMTP id 979FD6B0390 for ; Tue, 4 Apr 2017 18:55:22 -0400 (EDT) Received: by mail-it0-f70.google.com with SMTP id d69so52511707ith.20 for ; Tue, 04 Apr 2017 15:55:22 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com. [2607:f8b0:4001:c0b::22c]) by mx.google.com with ESMTPS id h63si19574050ioi.182.2017.04.04.15.55.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 15:55:21 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e75so73520762itd.1 for ; Tue, 04 Apr 2017 15:55:21 -0700 (PDT) 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 15:55:21 -0700 Message-ID: Subject: Re: sudo x86info -a => kernel BUG at mm/usercopy.c:78! Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Kees Cook Cc: Tommi Rantala , Dave Jones , Linux-MM , LKML , Laura Abbott , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Eric Biggers On Tue, Apr 4, 2017 at 3:37 PM, Kees Cook wrote: > > For one of my systems, I see something like this: > > 00000000-00000fff : reserved > 00001000-0008efff : System RAM > 0008f000-0008ffff : reserved > 00090000-0009f7ff : System RAM > 0009f800-0009ffff : reserved That's fairly normal. > I note that there are two "System RAM" areas below 0x100000. Yes. Traditionally the area from about 4k to 640kB is RAM. With a random smattering of BIOS areas. > * On x86, access has to be given to the first megabyte of ram because that area > * contains BIOS code and data regions used by X and dosemu and similar apps. Rigth. Traditionally, dosemu did one big mmap of the 1MB area to just get all the BIOS data in one go. > This means that it allows reads into even System RAM below 0x100000, > but I think that's a mistake. What you think is a "mistake" is how /dev/mem has always worked. /dev/mem gave access to all the memory of the system. That's LITERALLY the whole point of it. There was no "BIOS area" or anything else. It was access to physical memory. We've added limits to it, but those limits came later, and they came with the caveat that lots of programs used /dev/mem in various ways. Nobody was crazy enough to read /dev/mem one byte at a time trying to follow BIOS tables. No, the traditional way was to just map (or read) large chunks of it, and then follow the tables in the result. The easiest way was to just do the whole low 1MB. There's no "mistake" here. The only thing that is mistaken is you thinking that we can redefine reality and change history. 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. Linus -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org