Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 6 Apr 2022 12:45:56 -0700 | From | Kees Cook <> | Subject | Re: [PATCH v4] /dev/mem: Revoke mappings when a driver claims the region |
| |
*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@chromium.org> > > 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
| ![\](/images/icornerr.gif) |