On Wed, Apr 6, 2022 at 12:46 PM Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > *thread necromancy* It's alive! > > Hi Dan, > > I'm doing a KSPP bug scrub and am reviewing > https://github.com/KSPP/linux/issues/74 again. > > Do you have a chance to look at this? I'd love a way to make mmap() > behave the same way as read() for the first meg of /dev/mem. You want 0-reads or SIGBUS when attempting to access the first 1MB? Because it sounds like what you want is instead of loudly failing with -EPERM in drivers/char/mem.c::mmap_mem() you want it to silently succeed but swap in the zero page, right? Otherwise if it's SIGBUS then IO_STRICT_DEVMEM=y + marking that span as IORESOURCE_BUSY will "Do the Right Thing (TM).". > > -Kees > > On Thu, May 21, 2020 at 08:01:53PM -0700, Kees Cook wrote: > > On Thu, May 21, 2020 at 02:06:17PM -0700, Dan Williams wrote: > > > The typical usage of unmap_mapping_range() is part of > > > truncate_pagecache() to punch a hole in a file, but in this case the > > > implementation is only doing the "first half" of a hole punch. Namely it > > > is just evacuating current established mappings of the "hole", and it > > > relies on the fact that /dev/mem establishes mappings in terms of > > > absolute physical address offsets. Once existing mmap users are > > > invalidated they can attempt to re-establish the mapping, or attempt to > > > continue issuing read(2) / write(2) to the invalidated extent, but they > > > will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can > > > block those subsequent accesses. > > > > Nice! > > > > Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> > > > > And a thread hijack... ;) > > > > I think this is very close to providing a way to solve another issue > > I've had with /dev/mem, which is to zero the view of the first 1MB of > > /dev/mem via mmap. I only fixed the read/write accesses: > > a4866aa81251 ("mm: Tighten x86 /dev/mem with zeroing reads") > > I.e. the low 1MB range should be considered allowed, but any reads will see > > zeros. > > > > > + unmap_mapping_range(inode->i_mapping, res->start, resource_size(res), 1); > > > > Is unmap_mapping_range() sufficient for this? Would it need to happen > > once during open_port() or something more special during mmap_mem()? > > > > -- > > Kees Cook > > -- > Kees Cook
