On Mon, Feb 18, 2019 at 04:16:34PM +0100, Mark Kettenis wrote: > > Date: Mon, 18 Feb 2019 14:32:34 +0100 > > From: Hans-Joerg Hoexer <[email protected]> > > > > Hi, > > > > On Mon, Feb 18, 2019 at 01:51:58PM +0100, Mark Kettenis wrote: > > > > > > I suspect the direct map has to work for things like GDB's "target > > > kvm" to work. Otherwise inspecting the contents of some of the memory > > > pools will fail. > > > > sounds plausible. > > > > > You seem to imply that you can crash the kernel by just reading some > > > random memory address. That surprises me somewhat, even though I > > > think I managed to do exactly that not too long ago. In principle the > > > data is read using kcopy(9), which should recover and return an error > > > if we get a fault. Makes me wonder if somehow the trap handling is > > > subtly broken on amd64. Do you have more details on how you triggered > > > the kernel crash? > > > > I do this: > > > > ha-gs61# dd if=/dev/kmem of=/dev/null bs=1M count=1 skip=1801439743574 > > kernel: protection fault trap, code=0 > > Stopped at copyout+0x53: repe movsq (%rsi),%es:(%rdi) > > ddb{3}> > > > > Note that the accessed address is 0x1a36e2d0e5600000 which is > > non-conforming (or was it non-cannonical?) as it lies whithin the VA hole. > > Thanks! That explains why the kernel crashes. We handle T_PAGEFLT > kernel faults, but not T_PROTFLT. Phiip, Mike, any thoughts on that? > > If that is a consequence of the noncanonical address, I'd say crashing > is indeed the right thing to do as applying the proposed fix should > take care of avoiding this for /dev/kmem access. >
I think guenther@ cleaned up some of this handling in the past few weeks after we did the rdmsr_safe fix. For what it's worth, i386 has special handling of T_PROTFLT for the kvm case, but it looks like this was never (?) implemented for amd64? guenther? -ml
