[Crash-utility] The problems when running SuSE 12 on VirtualBox

Dave Anderson anderson at redhat.com
Thu Nov 19 16:24:45 UTC 2015



----- 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




More information about the Crash-utility mailing list