linux-kernel - Re: [PATCH v13 13/35] KVM: Introduce per-page memory attributes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZT9lQ9c7Bik6FIpw@chao-email>
Date:   Mon, 30 Oct 2023 16:11:47 +0800
From:   Chao Gao <chao.gao@...el.com>
To:     Sean Christopherson <seanjc@...gle.com>
CC:     Paolo Bonzini <pbonzini@...hat.com>, Marc Zyngier <maz@...nel.org>,
        "Oliver Upton" <oliver.upton@...ux.dev>,
        Huacai Chen <chenhuacai@...nel.org>,
        "Michael Ellerman" <mpe@...erman.id.au>,
        Anup Patel <anup@...infault.org>,
        "Paul Walmsley" <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <kvm@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
        <kvmarm@...ts.linux.dev>, <linux-mips@...r.kernel.org>,
        <linuxppc-dev@...ts.ozlabs.org>, <kvm-riscv@...ts.infradead.org>,
        <linux-riscv@...ts.infradead.org>, <linux-fsdevel@...r.kernel.org>,
        <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
        Xiaoyao Li <xiaoyao.li@...el.com>,
        Xu Yilun <yilun.xu@...el.com>,
        Chao Peng <chao.p.peng@...ux.intel.com>,
        Fuad Tabba <tabba@...gle.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Anish Moorthy <amoorthy@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Yu Zhang <yu.c.zhang@...ux.intel.com>,
        Isaku Yamahata <isaku.yamahata@...el.com>,
        Mickaël Salaün <mic@...ikod.net>,
        Vlastimil Babka <vbabka@...e.cz>,
        Vishal Annapurve <vannapurve@...gle.com>,
        Ackerley Tng <ackerleytng@...gle.com>,
        "Maciej Szmigiero" <mail@...iej.szmigiero.name>,
        David Hildenbrand <david@...hat.com>,
        Quentin Perret <qperret@...gle.com>,
        Michael Roth <michael.roth@....com>,
        Wang <wei.w.wang@...el.com>,
        Liam Merwick <liam.merwick@...cle.com>,
        "Isaku Yamahata" <isaku.yamahata@...il.com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v13 13/35] KVM: Introduce per-page memory attributes

On Fri, Oct 27, 2023 at 11:21:55AM -0700, Sean Christopherson wrote:
>From: Chao Peng <chao.p.peng@...ux.intel.com>
>
>In confidential computing usages, whether a page is private or shared is
>necessary information for KVM to perform operations like page fault
>handling, page zapping etc. There are other potential use cases for
>per-page memory attributes, e.g. to make memory read-only (or no-exec,
>or exec-only, etc.) without having to modify memslots.
>
>Introduce two ioctls (advertised by KVM_CAP_MEMORY_ATTRIBUTES) to allow
>userspace to operate on the per-page memory attributes.
>  - KVM_SET_MEMORY_ATTRIBUTES to set the per-page memory attributes to
>    a guest memory range.

>  - KVM_GET_SUPPORTED_MEMORY_ATTRIBUTES to return the KVM supported
>    memory attributes.

This ioctl() is already removed. So, the changelog is out-of-date and needs
an update.

>
>+
>+:Capability: KVM_CAP_MEMORY_ATTRIBUTES
>+:Architectures: x86
>+:Type: vm ioctl
>+:Parameters: struct kvm_memory_attributes(in)

					   ^ add one space here?


>+static bool kvm_pre_set_memory_attributes(struct kvm *kvm,
>+					  struct kvm_gfn_range *range)
>+{
>+	/*
>+	 * Unconditionally add the range to the invalidation set, regardless of
>+	 * whether or not the arch callback actually needs to zap SPTEs.  E.g.
>+	 * if KVM supports RWX attributes in the future and the attributes are
>+	 * going from R=>RW, zapping isn't strictly necessary.  Unconditionally
>+	 * adding the range allows KVM to require that MMU invalidations add at
>+	 * least one range between begin() and end(), e.g. allows KVM to detect
>+	 * bugs where the add() is missed.  Rexlaing the rule *might* be safe,

					    ^^^^^^^^ Relaxing

>@@ -4640,6 +4850,17 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> 	case KVM_CAP_BINARY_STATS_FD:
> 	case KVM_CAP_SYSTEM_EVENT_DATA:
> 		return 1;
>+#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
>+	case KVM_CAP_MEMORY_ATTRIBUTES:
>+		u64 attrs = kvm_supported_mem_attributes(kvm);
>+
>+		r = -EFAULT;
>+		if (copy_to_user(argp, &attrs, sizeof(attrs)))
>+			goto out;
>+		r = 0;
>+		break;

This cannot work, e.g., no @argp in this function and is fixed by a later commit:

	fcbef1e5e5d2 ("KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory")