Re: [RFC] Expose a memory poison detector ioctl to user space.

[David Hildenbrand <david@redhat.com>]

On 26.04.22 21:39, Dave Hansen wrote:
> On 4/26/22 12:23, Jue Wang wrote:
>> On Tue, Apr 26, 2022 at 11:18 AM Dave Hansen <dave.hansen@intel.com> wrote:
>>> What if you're in a normal (non-TDX) guest and some of the physical
>>> address space has been ballooned away?
>>
>> Accessing to memory that gets ballooned away will cause extra EPT
>> violations and have the memory faulted in on the host side, which is
>> transparent to the guest.
> 
> Yeah, but it completely subverts the whole purpose of ballooning.  In
> other words, this is for all intents and purposes also mutually
> exclusive with ballooning.

Some balloon (or balloon-like) implementations don't support reading
memory that's mapped into the direct map. For example, with never
virtio-mem devices in the hypervisor, reading unplugged memory can
result in undefined behavior (in the worst case, you'll get your VM zapped).

Reading random physical memory ranges without further checks is a very
bad idea. There are more corner cases, that we e.g., exclude when
reading /proc/kcore.

Take a look at read_kcore() KCORE_RAM case, where we e.g., exclude
reading PageOffline(), is_page_hwpoison() and !pfn_is_ram(). Unaccepted
memory might be another case we want to exclude there in the future.


I assume something as you imagine could be implemented in user space
just by relying on /proc/iomem and /proc/kcore right now in an unsafe
way. So you might want something similar, however, obviously without
exporting page content to user space and requiring root permissions.

-- 
Thanks,

David / dhildenb