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 DE178C77B7A for ; Fri, 19 May 2023 17:32:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEBB8900004; Fri, 19 May 2023 13:32:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E746F900003; Fri, 19 May 2023 13:32:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1501900004; Fri, 19 May 2023 13:32:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id BC033900003 for ; Fri, 19 May 2023 13:32:37 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 895B1140A7E for ; Fri, 19 May 2023 17:32:37 +0000 (UTC) X-FDA: 80807699154.14.4A6E807 Received: from smtp-fw-80009.amazon.com (smtp-fw-80009.amazon.com [99.78.197.220]) by imf03.hostedemail.com (Postfix) with ESMTP id 433BC20014 for ; Fri, 19 May 2023 17:32:33 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=q9muK6Fh; dmarc=pass (policy=quarantine) header.from=amazon.com; spf=pass (imf03.hostedemail.com: domain of "prvs=496baf2b8=nsaenz@amazon.es" designates 99.78.197.220 as permitted sender) smtp.mailfrom="prvs=496baf2b8=nsaenz@amazon.es" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684517554; h=from:from:sender: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:dkim-signature; bh=CDpNYbYopL6l908P9YpiX0NY2dAoYXZOF2ciVkFIcHY=; b=gV3ZDWADS+pr5EPTuHRQECzhbS7z6Z9aPHvproNNMQtuo6iogMEVFaCIhs9NR6MVyIkTfD 1xHan8h/TKfL9NEPdrihZvlMqsLJVRa3G65bsPzGif0wcfZ/d15udyqrssB9qDmlHsR2BK H38FXYW/yvPESVPRQIGpOe6LGbePq+I= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b=q9muK6Fh; dmarc=pass (policy=quarantine) header.from=amazon.com; spf=pass (imf03.hostedemail.com: domain of "prvs=496baf2b8=nsaenz@amazon.es" designates 99.78.197.220 as permitted sender) smtp.mailfrom="prvs=496baf2b8=nsaenz@amazon.es" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684517554; a=rsa-sha256; cv=none; b=kfyeNIxGcunGbuDcNEZ0JWfHkTyvUDdXGyVaucKal8tyySOxSl/Uez6I4aQdY6EhdWS46e S//PkqaRWgGtJEjXP4VEv10AAeltZL2Z4SkpJmd8XPd57Q4WwIfUjR7Wm4497jx5cYxfaE H7npdF3DI045jrWLN5wXqBsEPdIHGmI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1684517554; x=1716053554; h=mime-version:content-transfer-encoding:date:cc:subject: from:to:message-id:references:in-reply-to; bh=CDpNYbYopL6l908P9YpiX0NY2dAoYXZOF2ciVkFIcHY=; b=q9muK6FhsVU6fu8sbWy8rpdhRchATHdLI8YQk5ATZ1SifO0o4ZA/J9O+ FV6Cuf4OKPFO/PQzjdK17GxP2uNEw4yltiz9DHBn+fVEGcLqkcBcPKNnb /yApgnaXoyDfBrCZ8jDhE0QLiILDS4SwYPvfHlFWk4cIkeovyDH1Khlb7 8=; X-IronPort-AV: E=Sophos;i="6.00,177,1681171200"; d="scan'208";a="4343439" Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-pdx-2c-m6i4x-f7c754c9.us-west-2.amazon.com) ([10.25.36.214]) by smtp-border-fw-80009.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2023 17:32:31 +0000 Received: from EX19D004EUC001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan2.pdx.amazon.com [10.236.137.194]) by email-inbound-relay-pdx-2c-m6i4x-f7c754c9.us-west-2.amazon.com (Postfix) with ESMTPS id 9037C40D80; Fri, 19 May 2023 17:32:28 +0000 (UTC) Received: from localhost (10.13.235.138) by EX19D004EUC001.ant.amazon.com (10.252.51.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Fri, 19 May 2023 17:32:14 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Fri, 19 May 2023 17:32:10 +0000 CC: Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , "Joerg Roedel" , Thomas Gleixner , "Ingo Molnar" , Borislav Petkov , "Arnd Bergmann" , Naoya Horiguchi , Miaohe Lin , , "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , "Andrew Morton" , Shuah Khan , "Mike Rapoport" , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , , , , , , , , , Quentin Perret , , Michael Roth , , , Subject: Re: [PATCH v10 2/9] KVM: Introduce per-page memory attributes From: Nicolas Saenz Julienne To: Chao Peng , , , , , , , , , , Message-ID: X-Mailer: aerc 0.15.2-21-g30c1a30168df-dirty References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> <20221202061347.1070246-3-chao.p.peng@linux.intel.com> In-Reply-To: <20221202061347.1070246-3-chao.p.peng@linux.intel.com> X-Originating-IP: [10.13.235.138] X-ClientProxiedBy: EX19D037UWB001.ant.amazon.com (10.13.138.123) To EX19D004EUC001.ant.amazon.com (10.252.51.190) X-Rspamd-Queue-Id: 433BC20014 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: eyeahxbwnp8kuedoitt19ej9p81q75np X-HE-Bulk: true X-HE-Tag: 1684517553-202102 X-HE-Meta: U2FsdGVkX1+FBE5mVd66f98LxchzFfw2j5yj9gBSUeqRsNWs99/ZnOq+eTZIAGyLJzA6/3lomoS0YQGU30vGmI7RYGPzxkeW87XPQHk0jPIUcgK/t7d285uU+jdtYEmfvD5UX8Y95SyLqaILpZjiQ+TPE2B+GojagpLnHkXvb7DX0YbPw0ZLIfHstTGfQcbv1ehWqPBnoti2Hh47AlDJhaQeEmBuV4yB+znREUBjyHe4jwNC/U2ObVCd2mcfGl8gBK36krpXEus7jmLQZa5QasROkkMyM60oI+qLfvh7zsKlCSxFFBdi7Q+cXwJMxb6RqOpb9nmmFllaEgjmfPkub/24ytadhQ0RRkLtASCdWvW10R8FjCUHVeTHob3VVL6y+i+Kzje+HvEZHUqpHM5XqjELseIiNymtUouBM28FDwnVCplRsC6oXuO6k847dSxr82tnT0JhNxORfARiZV7XDLY7ti/G4u33mp6i3TFeGsaniwwQnuvaP8HIYlMvUsT9RqEWHmS/Ur5onnE8UR4pVZQ+kKFefwMYPCx5q1QVu4WwU85lRwPghwINSLH6c1bpre4ErdB5Kn1CqFfCWgtrfzK9pZTUc2EkVcIoSypr+gQoumnNOyHlP9lmpNzHe8irma5nLK3Pf8N7WiTLjqi99edXaoStEVmYVq4sjfLKqYY0xVjSLKNak+Z91epd/AUCVEmZCkxdG4vLlZBPx2QxWtBuKAYFRcWHi90ZdModzFekDeRbfpSv9UQ70EDr0IkgYD7kB2ERrdg8EDY91G7ij4CVFhfXNDbyYoYSRbCP1VInmq2/Vnw+73tS6V3oWGwV5a/BheP8Z4jrEQ02AcHnL40Zxos6EA8+vtrYLGIDuZcVzCMYetUxstx3GmmkPm3QunJHcDgpMiLiZIRTgblnLys+4HZ5jFKRWGg5fJkJvxHrNHf5uCHgN93XYFrqG6+jFghBKODB/8FvUN8JpSK 4lXO3YZQ 2kelAsQoJgDRYCNp+dUo932R4C5y+gnyajGupWgaA2d5ttWgZAPGe7lO5bU4b5afXf7Ca8iXYgLwiM4S4JLDdNuUWuK5N3eKnebpyZGrdWPNOrSZjhmWOipwcbj7R3B/xblHcke1zr7QxKaUjy1EgF5Oee1QGe9chS1yPpHdcbzSJaW8ynM5dPgG5er3T8FSrSDVwW5O110ey1m+o/VEytLMX/A786wzR1T6rIsNzqpCxmO30PRmlNowkklfRyAX7O3x/eQlGgRBmEt9zkHRc4wxPVeiu79U17SLtvQ1uNDbjfEqtdQ5VEQgz3JDczrzuAIsDV4pVSZy9g/4BMXNgJFBIcKAKwOOQHUNjsj+Ymv2wmbgi0yW9RGyL/m2e4/F3kLMKeWHtq+wwfN805/Eh3zGB8krTnyBPeE+yrZIWtyz/p4i4o2aJlh39NRFnbADzlofJFmIydDlybgiyEvTzejMOrA+2ee0+L9A8VmYkih5qGLdsHt7Q6plmdAUkZvcOQzVUMoFDyHhfNy2HvokdPBE1wi0JSROdAdxbJynXoWSeXbgfyDy3QHLgPN66b4Zck5NIQaPjF7UNkMsbZJV3pSWRmZq3BFTtjnybHEZRjRoOe8KllpUGQHLhM7UVw8XKSMlerBUnmHbVKSHxttlV6F0vF0cz7NoQJAx/z4lhG1Ud/vXtrI6uvwHZVOlJSNnusmZZ 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: Hi, On Fri Dec 2, 2022 at 6:13 AM UTC, Chao Peng wrote: [...] > +4.138 KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES > +----------------------------------------- > + > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES > +:Architectures: x86 > +:Type: vm ioctl > +:Parameters: u64 memory attributes bitmask(out) > +:Returns: 0 on success, <0 on error > + > +Returns supported memory attributes bitmask. Supported memory attributes= will > +have the corresponding bits set in u64 memory attributes bitmask. > + > +The following memory attributes are defined:: > + > + #define KVM_MEMORY_ATTRIBUTE_READ (1ULL << 0) > + #define KVM_MEMORY_ATTRIBUTE_WRITE (1ULL << 1) > + #define KVM_MEMORY_ATTRIBUTE_EXECUTE (1ULL << 2) > + #define KVM_MEMORY_ATTRIBUTE_PRIVATE (1ULL << 3) > + > +4.139 KVM_SET_MEMORY_ATTRIBUTES > +----------------------------------------- > + > +:Capability: KVM_CAP_MEMORY_ATTRIBUTES > +:Architectures: x86 > +:Type: vm ioctl > +:Parameters: struct kvm_memory_attributes(in/out) > +:Returns: 0 on success, <0 on error > + > +Sets memory attributes for pages in a guest memory range. Parameters are > +specified via the following structure:: > + > + struct kvm_memory_attributes { > + __u64 address; > + __u64 size; > + __u64 attributes; > + __u64 flags; > + }; > + > +The user sets the per-page memory attributes to a guest memory range ind= icated > +by address/size, and in return KVM adjusts address and size to reflect t= he > +actual pages of the memory range have been successfully set to the attri= butes. > +If the call returns 0, "address" is updated to the last successful addre= ss + 1 > +and "size" is updated to the remaining address size that has not been se= t > +successfully. The user should check the return value as well as the size= to > +decide if the operation succeeded for the whole range or not. The user m= ay want > +to retry the operation with the returned address/size if the previous ra= nge was > +partially successful. > + > +Both address and size should be page aligned and the supported attribute= s can be > +retrieved with KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES. > + > +The "flags" field may be used for future extensions and should be set to= 0s. We have been looking into adding support for the Hyper-V VSM extensions which Windows uses to implement Credential Guard. This interface seems like a good fit for one of its underlying features. I just wanted to share a bit about it, and see if we can expand it to fit this use-case. Note that this was already briefly discussed between Sean and Alex some time ago[1]. VSM introduces isolated guest execution contexts called Virtual Trust Levels (VTL) [2]. Each VTL has its own memory access protections, virtual processors states, interrupt controllers and overlay pages. VTLs are hierarchical and might enforce memory protections on less privileged VTLs. Memory protections are enforced on a per-GPA granularity. The list of possible protections is: - No access -- This needs a new memory attribute, I think. - Read-only, no execute - Read-only, execute - Read/write, no execute - Read/write, execute We implemented this in the past by using a separate address space per VTL and updating memory regions on protection changes. But having to update the memory slot layout for every permission change scales poorly, especially as we have to perform 100.000s of these operations at boot (see [1] for a little more context). I believe the biggest barrier for us to use memory attributes is not having the ability to target specific address spaces, or to the very least having some mechanism to maintain multiple independent layers of attributes. Also sorry for not posting our VSM patches. They are not ready for upstream review yet, but we're working on it. Nicolas [1] https://patchwork.kernel.org/comment/25054908/ [2] See Chapter 15 of Microsoft's 'Hypervisor Top Level Functional Specific= ation': https://raw.githubusercontent.com/MicrosoftDocs/Virtualization-Document= ation/main/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v6.= 0b.pdf