----- Original Message ----- > On 11/19/2015 08:56 AM, Dave Anderson wrote: > > > > > > ----- Original Message ----- > >>> > >>> So my questions are: > >>> > >>> (1) Is it OK to use "/proc/kcore" instead of "/dev/mem" as a workaround? > >>> Is there any side-effect? > >> > >> As I read it, /proc/kcore is the kernel's virtual address space and > >> /dev/mem is the system's physical address space. It probably isn't wise > >> to debug the latter on any dom0 (whether nested in another > >> virtualization or not) except in very acute cases. It may explain the > >> problem you were having in the first place if VirtualBox affects whether > >> /dev/mem is a real physical memory view or if it doesn't then whether > >> VirtualBox itself affects those cases where, as I understand it, the > >> kernel has constant physical addresses for some things. > > > > Hi Dave, > > > > I'm not sure why /proc/kcore should be considered unwise? Even with a Xen > > dom0 kernel, if it works, it works. All that crash is doing is taking the > > physical address it normally would use for reading from /dev/mem (or /dev/crash), > > and turning it into a unity-mapped kernel virtual address that it reads from > > /proc/kcore. I might be missing something, but it would seem like the > > virtualization aspect would be a non-issue? > > > > /proc/kcore is a problem with 32-bit kernels, which cannot unity-map physical > > memory above 896MB, but even with those, the session still comes up, albeit > > slightly crippled. > > It's my suspicion that many virtualization developers and some users > would consider it to be insecure to be able to read the memory of domUs > in the debugger itself when debugging the dom0 (other than when handling > desperate problems) OK, I'm was just concerned with whether /proc/kcore works as a functional replacement for /dev/mem, and not any "security" issues per se. Dave Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
