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