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

[David Hildenbrand <david@redhat.com>]

On 02.05.22 19:36, Jue Wang wrote:
> On Mon, May 2, 2022 at 10:33 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 02.05.22 19:30, Jue Wang wrote:
>>> On Mon, May 2, 2022 at 10:19 AM David Hildenbrand <david@redhat.com> wrote:
>>>>
>>>> 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.
>>>
>>> Are the following cases benign if the scan only happens on the host side?
>>>
>>> . virtio-mem - unplugged memory
>>> . Unaccepted memory
>>
>> No, only in virtualized worlds.
>>
>> I assume GART memory that implements the pfn_is_ram() callback is around
>> on physical machines.
> 
> I think host E820 provides an accurate view of which address range is
> ram or not?

On most physical machines maybe to some degree. It doesn't hold for
physically hot(un)plugged memory and I remember GART memory is special.
No idea how that is exposed in e820.

-- 
Thanks,

David / dhildenb