David Miller wrote: [Tue Sep 09 2014, 06:07:42PM EDT] > From: Bob Picco <bpicco@xxxxxxxxxx> > Date: Sun, 7 Sep 2014 11:48:45 -0400 > > > From: bob picco <bpicco@xxxxxxxxxx> > > > > This patch attempts to restrict mmap of /dev/mem. It tightens up the bus > > error (DTLB errors) issues related to mmap of /dev/mem. > > > > A root privileged application like python using dmidecode mmap-s /dev/mem to > > examine an x86 magic area which is non-existent on sparc64. This results > > in a power off event within sun4v_dtlb_error_report because the HV reports > > an invalid RA. > > > > The mmap restriction of /dev/mem does introduce ARCH_HAS_VALID_PHYS_ADDR_RANGE. > > This does cause us to clone the functionality of valid_phys_addr_range. A > > mapper is not allowed to mmap a range which isn't kern_addr_valid true on > > every 4Mb boundary. > > > > Cc: sparclinux@xxxxxxxxxxxxxxx > > Reviewed-by: Dave Kleikamp <dave.kleikamp@xxxxxxxxxx> > > Signed-off-by: Bob Picco <bob.picco@xxxxxxxxxx> > > I think the fact that you are defining the restriction for read/write > differently for mmap should give you some pause. > > There really should be no difference. > > The reason you're doing this is because if we access the physical > address on the kernel side and it's a bad RA, we fault cleanly, > whereas if the user does this we do not. > > And I think, given this, the real fix is to make user side accesses > recover cleanly just as the kernel ones do. > > Therefore, this kind of continues the feedback for the TLB error > handling patch we've been discussing. > > It seems to me that if the hypervisor errors out with "BAD RA", and we > are accessing a user page, we can just bus error the process. > > What do you think? Let's abandon this patch. In a common part for DTLB/ITLB "BAD RA" check TSTATE_PRIV. Should we not be privileged raise a bus error with SIGBUS and BUS_ADRERR for the task. How does this sound? thanx, bob > -- > To unsubscribe from this list: send the line "unsubscribe sparclinux" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
