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

[Jue Wang <juew@google.com>]

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


>
> --
> Thanks,
>
> David / dhildenb
>