From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F34A801 for ; Thu, 19 Dec 2024 13:01:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734613286; cv=none; b=CvFeytXEDbSB253JcSEojUwmnqxswc97WNjCK6zGB1xoeriBzXUfZ+Xw2WzevL3DSUMM+yuZUnvCgjM/vQxZscuox6bZo4Oh9uzXzMM74mAoYqprCPXyxApnDJwJH9eIzxRn19s406OyUDxuxI0Kxp4MWPV2IQxIboxtNEvPZKU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734613286; c=relaxed/simple; bh=O3IkwvJlk6EBCbr2lI7kMh54S9htt+kwglnpdJT+ukE=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=nYD948oDKcQJaMBXKf/XuF1kWA0UVvZ2lQwcluRIsqVKpbAz2wzncdg4JNz0fbbtSI37K6Xw1bW/5/ycvP2RiIVgBQpBKk9Mf0Eu/LBaud8G7jBk14mpEocF65va1Ng0+cRln7saFc8XIqJrl8SQKy6UGuYSoul6ODepjorNWMM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h3TIdzt5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="h3TIdzt5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D95EC4CECE; Thu, 19 Dec 2024 13:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734613285; bh=O3IkwvJlk6EBCbr2lI7kMh54S9htt+kwglnpdJT+ukE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=h3TIdzt5xtQnJM11PaGOl95b1BWvsSe+ZHJeBjhc31RHJgMZejnO1qDTuQfovc7TA VwHy4cegzvveiwVKVCUJsqpLT01aPf5OQHz1VAZZVabKGxvMvzhy8EKN8Au0F8v132 d0/mAoKgfZ6P+JW+yHGxDSlAAQNt5pbN5mmVnIHXkIPfFXGCaDnbsmgggvYFmJcgQ6 45lWnARrnByJ+BayzFIMnEciYmiq+crassTiJ4f295vWgONIvnY1+k+6XkBlXyu+Ly voDsBzEOce4+quovWgOWv7uxL8WXfIXeJODctp9WBgyOtiq96yqT0PHADbAkeFqLil vqSFVTU2CBidw== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tOG9b-005GyE-BC; Thu, 19 Dec 2024 13:01:23 +0000 Date: Thu, 19 Dec 2024 13:01:22 +0000 Message-ID: <861py3rfml.wl-maz@kernel.org> From: Marc Zyngier To: Daniel =?UTF-8?B?IlAuIEJlcnJhbmfDqSI=?= Cc: Kashyap Chamarthy , Eric Auger , Cornelia Huck , eric.auger.pro@gmail.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, kvmarm@lists.linux.dev, peter.maydell@linaro.org, richard.henderson@linaro.org, alex.bennee@linaro.org, oliver.upton@linux.dev, sebott@redhat.com, shameerali.kolothum.thodi@huawei.com, armbru@redhat.com, abologna@redhat.com, jdenemar@redhat.com, shahuang@redhat.com, mark.rutland@arm.com, philmd@linaro.org, pbonzini@redhat.com Subject: Re: [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable aarch64 KVM host model In-Reply-To: References: <20241206112213.88394-1-cohuck@redhat.com> <8734it1bv6.fsf@redhat.com> <1fea79e4-7a31-4592-8495-7b18cd82d02b@redhat.com> <8634ijrh8q.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: berrange@redhat.com, kchamart@redhat.com, eric.auger@redhat.com, cohuck@redhat.com, eric.auger.pro@gmail.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, kvmarm@lists.linux.dev, peter.maydell@linaro.org, richard.henderson@linaro.org, alex.bennee@linaro.org, oliver.upton@linux.dev, sebott@redhat.com, shameerali.kolothum.thodi@huawei.com, armbru@redhat.com, abologna@redhat.com, jdenemar@redhat.com, shahuang@redhat.com, mark.rutland@arm.com, philmd@linaro.org, pbonzini@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 19 Dec 2024 12:38:50 +0000, Daniel "P. Berrang=C3=A9" wrote: >=20 > On Thu, Dec 19, 2024 at 12:26:29PM +0000, Marc Zyngier wrote: > > On Thu, 19 Dec 2024 11:35:16 +0000, > > Kashyap Chamarthy wrote: > > >=20 > > > On Thu, Dec 12, 2024 at 11:04:30AM +0100, Eric Auger wrote: > > >=20 > > > Hi Eric, > > >=20 > > > > On 12/12/24 10:36, Cornelia Huck wrote: > > > > > On Thu, Dec 12 2024, Daniel P. Berrang=C3=A9 wrote: > > >=20 > > > [...] > > >=20 > > > > >> Consider you mgmt app wants to set a CPU model that's common acr= oss > > > > >> heterogeneous hardware. They don't neccessarily want/need to be > > > > >> able to live migrate between heterogeneous CPUs, but for simplic= ity > > > > >> of configuration desire to set a single named CPU across all gue= sts, > > > > >> irrespective of what host hey are launched on. The ARM spec base= line > > > > >> named models would give you that config simplicity. > > > > > If we use architecture extensions (i.e. Armv8.x/9.x) as baseline,= I'm > > > > > seeing some drawbacks: > > > > > - a lot of work before we can address some specific use cases > > > > > - old models can get new optional features > > > > > - a specific cpu might have a huge set of optional features on to= p of > > > > > the baseline model > > > > > > > > > > Using a reference core such as Neoverse-V2 probably makes more se= nse > > > > > (easier to get started, less feature diff?) It would still make a= good > > > > > starting point for a simple config. > > > > > > > > > Actually from a dev point of view I am not sure it changes much to = have > > > > either ARM spec rev baseline or CPU ref core named model. > > > >=20 > > > > One remark is that if you look at > > > > https://developer.arm.com/documentation/109697/2024_09?lang=3Den > > > > you will see there are quite a lot of spec revisions and quite a fe= w of > > > > them are actually meaningful in the light of currently avaiable and > > > > relevant HW we want to address. What I would like to avoid is to be > > > > obliged to look at all of them in a generic manner while we just wa= nt to > > > > address few cpu ref models. > > > >=20 > > > > Also starting from the ARM spec rev baseline the end-user may need = to > > > > add more feature opt-ins to be close to a specific cpu model. So I > > > > foresee extra complexity for the end-user. > > >=20 > > > (Assuming I'm parsing your last para right; correct me if not.) > > >=20 > > > Isn't a user wanting to add extra CPU flags (on top of a baseline) a > > > "normal behaviour" and not "extra complexity"? Besides coming close = to > > > a specific CPU model, there's the additional important use-case of CPU > > > flags that provide security mitigation. > > >=20 > > > Consider this: > > >=20 > > > Say, there's a serious security issue in a released ARM CPU. As part= of > > > the fix, two new CPU flags need to be exposed to the guest OS, call t= hem > > > "secflag1" and "secflag2". Here, the user is configuring a baseline > > > model + two extra CPU flags, not to get close to some other CPU model > > > but to mitigate itself against a serious security flaw. > >=20 > > If there's such a security issue, that the hypervisor's job to do so, > > not userspace. See what KVM does for CSV3, for example (and all the > > rest of the side-channel stuff). > >=20 > > You can't rely on userspace for security, that'd be completely > > ludicrous. >=20 > Actually that's a normal situation QEMU has to deal with. >=20 > QEMU needs to be able to expose a deterministic fixed ABI to the guest > VM, and that includes control over what CPU features are exposed to > it. In most cases, the hypervisor cannot arbitrary force enable new > guest features without agreement from QEMU. Which ABI? The only ABI that matters is what is defined by the architecture. When it comes to CPU features, new features are exposed by default. If QEMU wants to turn it off, it can in most (but not all) cases. But that's the extent of the "agreement" we have with userspace, QEMU or otherwise. If a feature is deemed broken or unsafe, KVM will turn it at least hide it from the guest without userspace's intervention, and if possible actively turn it off. > If a guest happens to be using '-cpu host', then when a new CPU flag > arrives as part of a security fix, there is at least no CPU config > change required. QEMU may or may not need changes, in order that > the behaviour associated with the new CPU flag is correctly handled. How is that "flag" visible from the guest? The only way to expose properties is through the ID registers, and you can't invent your own, nor expose something that is not already handled by the host. > If the guest is using a named CPU model, as well as modifying QEMU > to know about the new flag, the host admin needs to explicitly > decide whether & when to expose the new CPU flag for each guest VM > on the host. > > Until the new CPU flag is exposed to the guest, while the host itself > may be able to remain protected to the new security issue, the guest > OS is likely remain vulnerable, or have degraded operation in some way. I think that's the point where we talk past each other. There is no "flag" that can be exposed to a guest as part of the architecture. We have a set of architectural features, and in 99% of the cases, we can only expose to the guest a feature that both exists on the host and that the hypervisor understands. Thanks, M. --=20 Without deviation from the norm, progress is not possible.