linux-kernel - Re: [PATCH v8 2/4] mm: introduce new flag to indicate wc safe

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: <bc5cdc2e-50d8-435a-8f9d-a0053a99598d@nvidia.com>
Date: Tue, 20 Feb 2024 08:26:39 +0000
From: Zhi Wang <zhiw@...dia.com>
To: Ankit Agrawal <ankita@...dia.com>, Jason Gunthorpe <jgg@...dia.com>,
	"maz@...nel.org" <maz@...nel.org>, "oliver.upton@...ux.dev"
	<oliver.upton@...ux.dev>, "james.morse@....com" <james.morse@....com>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>, "yuzenghui@...wei.com"
	<yuzenghui@...wei.com>, "reinette.chatre@...el.com"
	<reinette.chatre@...el.com>, "surenb@...gle.com" <surenb@...gle.com>,
	"stefanha@...hat.com" <stefanha@...hat.com>, "brauner@...nel.org"
	<brauner@...nel.org>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"will@...nel.org" <will@...nel.org>, "mark.rutland@....com"
	<mark.rutland@....com>, "alex.williamson@...hat.com"
	<alex.williamson@...hat.com>, "kevin.tian@...el.com" <kevin.tian@...el.com>,
	"yi.l.liu@...el.com" <yi.l.liu@...el.com>, "ardb@...nel.org"
	<ardb@...nel.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"andreyknvl@...il.com" <andreyknvl@...il.com>, "wangjinchao@...sion.com"
	<wangjinchao@...sion.com>, "gshan@...hat.com" <gshan@...hat.com>,
	"shahuang@...hat.com" <shahuang@...hat.com>, "ricarkol@...gle.com"
	<ricarkol@...gle.com>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"lpieralisi@...nel.org" <lpieralisi@...nel.org>, "rananta@...gle.com"
	<rananta@...gle.com>, "ryan.roberts@....com" <ryan.roberts@....com>,
	"david@...hat.com" <david@...hat.com>, "linus.walleij@...aro.org"
	<linus.walleij@...aro.org>, "bhe@...hat.com" <bhe@...hat.com>
CC: Aniket Agashe <aniketa@...dia.com>, Neo Jia <cjia@...dia.com>, Kirti
 Wankhede <kwankhede@...dia.com>, "Tarun Gupta (SW-GPU)"
	<targupta@...dia.com>, Vikram Sethi <vsethi@...dia.com>, Andy Currid
	<ACurrid@...dia.com>, Alistair Popple <apopple@...dia.com>, John Hubbard
	<jhubbard@...dia.com>, Dan Williams <danw@...dia.com>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>, Matt Ochs
	<mochs@...dia.com>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v8 2/4] mm: introduce new flag to indicate wc safe

On 2/20/24 07:29, Ankit Agrawal wrote:
> From: Ankit Agrawal <ankita@...dia.com>
> 
> The VM_ALLOW_ANY_UNCACHED flag is implemented for ARM64, allowing KVM
> stage 2 device mapping attributes to use NormalNC rather than
> DEVICE_nGnRE, which allows guest mappings supporting combining
> attributes (WC). ARM does not architecturally guarantee this is safe,
> and indeed some MMIO regions like the GICv2 VCPU interface can trigger
> uncontained faults if NormalNC is used.
> 
> Even worse we expect there are platforms where even DEVICE_nGnRE can
> allow uncontained faults in corner cases. Unfortunately existing ARM IP
> requires platform integration to take responsibility to prevent this.
> 
> To safely use VFIO in KVM the platform must guarantee full safety in the
> guest where no action taken against a MMIO mapping can trigger an
> uncontained failure. We belive that most VFIO PCI platforms support this

A nit, let's use passive voice in the patch comment. Also belive is mostly
a typo.

> for both mapping types, at least in common flows, based on some
> expectations of how PCI IP is integrated. This can be enabled more broadly,
> for instance into vfio-platform drivers, but only after the platform
> vendor completes auditing for safety.
> 
> The VMA flag VM_ALLOW_ANY_UNCACHED was found to be the simplest and
> cleanest way to communicate the information from VFIO to KVM that
> mapping the region in S2 as NormalNC is safe. KVM consumes it to
> activate the code that does the S2 mapping as NormalNC.
> 
> Suggested-by: Catalin Marinas <catalin.marinas@....com>
> Reviewed-by: Jason Gunthorpe <jgg@...dia.com>
> Acked-by: David Hildenbrand <david@...hat.com>
> Signed-off-by: Ankit Agrawal <ankita@...dia.com>
> ---
>   include/linux/mm.h | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f5a97dec5169..59576e56c58b 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -391,6 +391,20 @@ extern unsigned int kobjsize(const void *objp);
>   # define VM_UFFD_MINOR		VM_NONE
>   #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
>   
> +/*
> + * This flag is used to connect VFIO to arch specific KVM code. It
> + * indicates that the memory under this VMA is safe for use with any
> + * non-cachable memory type inside KVM. Some VFIO devices, on some
> + * platforms, are thought to be unsafe and can cause machine crashes
> + * if KVM does not lock down the memory type.
> + */
> +#ifdef CONFIG_64BIT
> +#define VM_ALLOW_ANY_UNCACHED_BIT	39
> +#define VM_ALLOW_ANY_UNCACHED		BIT(VM_ALLOW_ANY_UNCACHED_BIT)
> +#else
> +#define VM_ALLOW_ANY_UNCACHED		VM_NONE
> +#endif
> +
>   /* Bits set in the VMA until the stack is in its final location */
>   #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
>