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 2F8CBC433F5 for ; Mon, 2 May 2022 17:19:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E9466B0071; Mon, 2 May 2022 13:19:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8707B6B0073; Mon, 2 May 2022 13:19:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3BA6B0074; Mon, 2 May 2022 13:19:33 -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 55D286B0071 for ; Mon, 2 May 2022 13:19:33 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2A62A2934A for ; Mon, 2 May 2022 17:19:33 +0000 (UTC) X-FDA: 79421464626.13.BBEAE26 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf13.hostedemail.com (Postfix) with ESMTP id 55E7D2007C for ; Mon, 2 May 2022 17:19:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1651511971; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fHFJyxQ9iddOjghLhwiL3Gj2L+RU2QoOL6tvaWy4fYs=; b=Dok8ANz8MTrFqmI/S2TznTpXY0Kl+FppcDKNsnQjxzmDB5tU2GAs4EJiD4mOQnizbc1sAm FN9uVG2RuRIycslDlrrtZaKRc12lUuhJ2bpHR6wVOV6UiqQ4ZVxkCP/ddfJRY1TBGcagsz /K25WZE3fTa3d6bziSLXS5ot/W+E7C4= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-172-5p4ZZbCyP3GMndCSpmjTFA-1; Mon, 02 May 2022 13:19:30 -0400 X-MC-Unique: 5p4ZZbCyP3GMndCSpmjTFA-1 Received: by mail-pf1-f198.google.com with SMTP id p18-20020aa78612000000b0050d1c170018so8330363pfn.15 for ; Mon, 02 May 2022 10:19:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=fHFJyxQ9iddOjghLhwiL3Gj2L+RU2QoOL6tvaWy4fYs=; b=tHNjWgwDGb+XBCK1TlYRE5elGNqvkH64BPszTsKbc1CCHAbddkVTTUv4/MFESU9oLh 9shVXW527Jesh651+SHCxW3JoctNgSJ/fPobFBbhBV/S6Pi/B5rSmbyKcZ7Xki50xB9l 1pLOOZ+2cDelGgB0y6U2lbCV+aUE3iWrxsAWOsNTqYoeWn7Pqn9FP4ocvME4JG/cqmkV 2dTuV/RmM3c28dHDVfARaHS7odzWYv+eVx6TOuLPuJrYhtUFZXzG7LaZxtBwDDBhJPfe dZRmWp4wc8zX5Wh0ZpLLf1sk37SIiuoDe8mJ/zEOEbaWuwN0GnJHVAauEV1jQ34Y2uDC I2tQ== X-Gm-Message-State: AOAM5323Hm6e0TcbCHE6QxBtX4XmtM8XmSmw8XJlGvNUzbotfTu0LZaD OFKO/hyQ+lhzqN5nbG0lVZ82Kc4fV7BO4z6bYUb8GxMj5q7jGRQfnoP8h5ey0+OiFvOGym+YrNl yDBsfaZDnk4c= X-Received: by 2002:a17:902:b7cb:b0:15c:6650:a58a with SMTP id v11-20020a170902b7cb00b0015c6650a58amr12714032plz.63.1651511969609; Mon, 02 May 2022 10:19:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+M/JKyfF+JDjetU/v7K4ktlXS6/r0MPl9mIqG9oU2MquqqnSYiQMQ12V5zDpNpra80Glnzw== X-Received: by 2002:a17:902:b7cb:b0:15c:6650:a58a with SMTP id v11-20020a170902b7cb00b0015c6650a58amr12714011plz.63.1651511969279; Mon, 02 May 2022 10:19:29 -0700 (PDT) Received: from [10.10.69.234] ([8.34.116.185]) by smtp.gmail.com with ESMTPSA id 38-20020a630f66000000b003c14af505fasm11254036pgp.18.2022.05.02.10.19.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 May 2022 10:19:28 -0700 (PDT) Message-ID: Date: Mon, 2 May 2022 19:19:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 To: Dave Hansen , Jue Wang Cc: Naoya Horiguchi , Tony Luck , Dave Hansen , Jiaqi Yan , Greg Thelen , Mina Almasry , linux-mm@kvack.org, Sean Christopherson References: <20220425163451.3818838-1-juew@google.com> <5a7f00e3-311d-b5ca-4249-7f50f8712559@intel.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] Expose a memory poison detector ioctl to user space. In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Dok8ANz8; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf13.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 55E7D2007C X-Rspam-User: X-Stat-Signature: 8di9diizm7xrfo8bgj8auicuoeutkbt3 X-HE-Tag: 1651511961-556230 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 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, David / dhildenb