From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f71.google.com (mail-it0-f71.google.com [209.85.214.71]) by kanga.kvack.org (Postfix) with ESMTP id E1B7E6B0390 for ; Fri, 31 Mar 2017 19:58:10 -0400 (EDT) Received: by mail-it0-f71.google.com with SMTP id 8so13533782itb.22 for ; Fri, 31 Mar 2017 16:58:10 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com. [2607:f8b0:4001:c06::234]) by mx.google.com with ESMTPS id d184si4291944itg.22.2017.03.31.16.58.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 16:58:10 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id f84so48827245ioj.0 for ; Fri, 31 Mar 2017 16:58:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170330194143.cbracica3w3ijrcx@codemonkey.org.uk> <20170331171724.nm22iqiellfsvj5z@codemonkey.org.uk> From: Kees Cook Date: Fri, 31 Mar 2017 16:58:09 -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: Linus Torvalds Cc: Dave Jones , Tommi Rantala , Linux-MM , LKML , Laura Abbott , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Eric Biggers On Fri, Mar 31, 2017 at 11:26 AM, Linus Torvalds wrote: > On Fri, Mar 31, 2017 at 10:32 AM, Kees Cook wrote: >> >> How is ffff880000090000 both in the direct mapping and a slab object? > > I think this is just very regular /dev/mem behavior, that is hidden by > the fact that the *normal* case for /dev/mem is all to reserved RAM, > which will never be a slab object. > > And this is all hidden with STRICT_DEVMEM, which pretty much everybody > has enabled, but Tommi for some reason did not. (It tripped under Fedora (with STRICT_DEVMEM) too, but I see below you isolated it...) > >> It would need to pass all of these checks, and be marked as PageSlab >> before it could be evaluated by __check_heap_object: > > It trivially passes those checks, because it's a normal kernel address > for a page that is just used for kernel stuff. > > I think we have two options: > > - just get rid of STRICT_DEVMEM and make that unconditional I'm a fan of this whatever the case; have all the video drivers moved away from crazy userspace direct memory access? (Or am I misremembering the reason for allowing /dev/mem to read RAM?) > - make the read_mem/write_mem code use some non-checking copy > routines, since they are obviously designed to access any memory > location (including kernel memory) unless STRICT_DEVMEM is set. I don't think this is a probably with the usercopy code: it is attempting to read RAM which should be blocked. It just _happens_ that this RAM got used for slab cache. > Hmm. Thinking more about this, we do allow access to the first 1MB of > physical memory unconditionally (see devmem_is_allowed() in Oooh, yes, that's the issue here. If the location is bypassing devmem_is_allowed(), oops. > arch/x86/mm/init.c). And I think we only _reserve_ the first 64kB or > something. So I guess even STRICT_DEVMEM isn't actually all that > strict. > > So this should be visible even *with* STRICT_DEVMEM. > > Does a simple > > sudo dd if=/dev/mem of=/dev/null bs=4096 count=256 > > also show the same issue? Maybe regardless of STRICT_DEVMEM? > > Maybe we should change devmem_is_allowed() to return a ternary value, > and then have it be "allow access" (for reserved pages), "disallow > access" (for various random stuff), and "just read zero" (for pages in > the low 1M that aren't marked reserved). If that doesn't break x86info, that would be nice too. > That way things like that read the low 1M (like x86info) will > hopefully not be unhappy, but also won't be reading random kernel > data. So, this seems like an uncommon situation where <1M memory ended up in as regular RAM. It seems like this exception is the problem? -Kees -- Kees Cook Pixel Security -- 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