From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 182ECC433F5 for ; Mon, 2 May 2022 17:36:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 925DB6B0073; Mon, 2 May 2022 13:36:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8D3496B0074; Mon, 2 May 2022 13:36:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7749A6B0075; Mon, 2 May 2022 13:36:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 657286B0073 for ; Mon, 2 May 2022 13:36:24 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3C8602A829 for ; Mon, 2 May 2022 17:36:24 +0000 (UTC) X-FDA: 79421507088.16.282C5C3 Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) by imf01.hostedemail.com (Postfix) with ESMTP id 71DEE4007F for ; Mon, 2 May 2022 17:36:16 +0000 (UTC) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-2f7bb893309so155365697b3.12 for ; Mon, 02 May 2022 10:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qva7bHIWnocjbf+qqPa20lxfkd/PWIYYehHQ+S1IGPA=; b=U5W3XRS9Oar/rvAJ9hmG35Pfny7KugrjD2N+D588juozzlbFPxbVtxqywTSw5q+N7x O6or+3VAIoYCyorLv08rUmpyYKR3I3fB00avq8j2I9M6Obr5lQ5C/CWKDyren79UfOfK SVnDhqoRBhO9F2G2ZH5h7wBK9VBAPgwUdLUhZoCdmlB4vJHxQ1Jt+emRF6zwdaUCSOHB HzZ+UFy2qyItwt647zwhVhQmErsa6frJdpAm4/WErp2yd+BtE+zZUUdK6B4yacBdpGDV EmGKKWP9dVYozXpZt2Kp2nApQ8WG8BaekZhFMaQYlwWMZkTlvig0iEkJMx325800z41J pKmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qva7bHIWnocjbf+qqPa20lxfkd/PWIYYehHQ+S1IGPA=; b=p58jrth8RYSAJQSx0BAQ1PL0On4gZydQHfHvNjSEO2JfD5jKX9XQrOiYDaONMA/UpL NlshdtVtDHmRsIE4uy/JWV4Yc/32i6UVKxrK9OMcA0KRkX0gTb1yuiLJJwjaJkGYaUXr qG9z8a7oG7kURd0+U6fO7g7+fbVqI2wL2o3rzs9UR37iLgoX36+ggcJv9Yw5upPi49nF IM8gnVaA9wshVBOHY+j0As57ZGaJxw/RBPs8K2215ic43DxXHKhrQZEZ4gFDSTy1J6GY A0l46zb/vLp/p/CkY+LgDczGYoI3OgPk6+0sKd19g0/dzHehY583P3khz0AhPZywZfs0 LUuQ== X-Gm-Message-State: AOAM533tbpFn6xeepA04/qrDTMfXoqeqjo4uA0lb7sdSi+xbTSSTjPbL A/q7H6DL0a0nwYLq0Xa5ahe5sR0mFwVlqwaRl9LgYQ== X-Google-Smtp-Source: ABdhPJzXJ9ZxVDZhr2mTtl9Zh1ZHPdZDZIofQi5nH6a6o40WF9V+vjgctICfhceKIFEZFD/p43VHu6fq13XYE6332mE= X-Received: by 2002:a0d:d80b:0:b0:2f7:c74f:7ca5 with SMTP id a11-20020a0dd80b000000b002f7c74f7ca5mr12189380ywe.489.1651512982165; Mon, 02 May 2022 10:36:22 -0700 (PDT) MIME-Version: 1.0 References: <20220425163451.3818838-1-juew@google.com> <5a7f00e3-311d-b5ca-4249-7f50f8712559@intel.com> <2b1d3a10-4a23-3787-dcfa-44f05554688c@redhat.com> In-Reply-To: <2b1d3a10-4a23-3787-dcfa-44f05554688c@redhat.com> From: Jue Wang Date: Mon, 2 May 2022 10:36:10 -0700 Message-ID: Subject: Re: [RFC] Expose a memory poison detector ioctl to user space. To: David Hildenbrand Cc: Dave Hansen , Naoya Horiguchi , Tony Luck , Dave Hansen , Jiaqi Yan , Greg Thelen , Mina Almasry , linux-mm@kvack.org, Sean Christopherson Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: czxpyn44dj4p88mr1tbpbi47bnnzxhhf X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 71DEE4007F Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=U5W3XRS9; spf=pass (imf01.hostedemail.com: domain of juew@google.com designates 209.85.128.171 as permitted sender) smtp.mailfrom=juew@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-HE-Tag: 1651512976-571516 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 2, 2022 at 10:33 AM David Hildenbrand wrote: > > On 02.05.22 19:30, Jue Wang wrote: > > On Mon, May 2, 2022 at 10:19 AM David Hildenbrand 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 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? > > > -- > Thanks, > > David / dhildenb >