*thread necromancy* 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. -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
