| Message ID | 20250217163732.3718617-3-kchamart@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | docs: Small changes to system/arm/cpu-features and more | expand |
Hi Kashyap, On 2/17/25 5:37 PM, Kashyap Chamarthy wrote: > PAuth (Pointer Authentication), a security feature in software, is > relevant for both KVM and QEMU. Relect this fact into the docs: > > - For KVM, `pauth` is a binary, "on" vs "off" option. The host CPU > will choose the cryptographic algorithm. > > - For TCG, however, along with `pauth`, a couple of properties can be > controlled -- they're are related to cryptographic algorithm choice. > > Thanks to Peter Maydell and Marc Zyngier for explaining more about PAuth > on IRC (#qemu, OFTC). > > Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> > --- > v2: address Marc Zyngier's comments: > https://lists.gnu.org/archive/html/qemu-devel/2025-01/msg03451.html > --- > docs/system/arm/cpu-features.rst | 46 +++++++++++++++++++++++++++++--- > 1 file changed, 42 insertions(+), 4 deletions(-) > > diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst > index a596316384..94d260b573 100644 > --- a/docs/system/arm/cpu-features.rst > +++ b/docs/system/arm/cpu-features.rst > @@ -204,11 +204,49 @@ the list of KVM vCPU features and their descriptions. > the guest scheduler behavior and/or be exposed to the guest > userspace. > > -TCG vCPU Features > -================= > +"PAuth" (Pointer Authentication) > +================================ > + > +PAuth (Pointer Authentication) is a security feature in software that > +was introduced in Armv8.3-A. It aims to protect against ROP > +(return-oriented programming) attacks. > + > +KVM > +--- > + > +``pauth`` > + > + Enable or disable ``FEAT_Pauth``. No other properties can be > + controlled. > + > + The host CPU will define the PAC (pointer authentication > + code) cryptographic algorithm. > + > + There are different "levels" of PAuth support. The host CPU > + definition will define that level (e.g. PAuth, EPAC, PAuth2, FPAC, > + FPACCOMBINE, etc). Refer to the Arm architecture extension documents > + for details about the description of these features. > + > +Live migration and PAuth > +~~~~~~~~~~~~~~~~~~~~~~~~ > + > +The level of PAuth support depends on which Arm architecture a given CPU > +supports (e.g. Armv8.3 vs. Armv8.6). This gradation in PAuth support > +has implications for live migration. For example, to be able to > +live-migrate from host-A (with Armv8.3) to host-B (with Arm v8.6): > + > + - the source and destination hosts must "agree" on (a) the PAC > + signature algorithm, and (b) all the sub-features of PAuth; or > + > + - the alternative (and less desirable) option is to turn off PAuth > + off on both source and destination — this is generally not > + recommended, as PAuth is a security feature. > + > +TCG > +--- > > -TCG vCPU features are CPU features that are specific to TCG. > -Below is the list of TCG vCPU features and their descriptions. The resulting header layout seems weird to me. Initially we had at top level (assuming ===): KVM vCPU Features TCG vCPU Features SVE CPU Properties SME CPU Properties RME CPU Properties and now TCG vCPU Features has somehow disappeared giving the impression that there are none. SME and RME and TCG only if am not wrong while PAUTH and SVE are both KVM and TCG Maybe we shall - rename KVM vCPU Features -> KVM only vCPU Features - Add a TCG only vCPU features including both SME and RME ones - introduce a top level KVM and TCG vCPU features with below: PAUTH, SVE, detailing potential different semantic for both KVM and TCG mode Also while we are at it, we may use vCPU everywhere instead of CPU (SVE CPU Properties) and just skip CPU if it lays within the KVM and TCG vCPU Features Thanks Eric > +For TCG, along with ``pauth``, it is possible to control a few other > +properties of PAuth: > > ``pauth`` > Enable or disable ``FEAT_Pauth`` entirely.
(Cc: Richard Henderson; context: "SME" and "RME" feature discussion below.) On Mon, Feb 17, 2025 at 06:43:01PM +0100, Eric Auger wrote: > Hi Kashyap, Hey, > > On 2/17/25 5:37 PM, Kashyap Chamarthy wrote: [...] > > Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> > > --- > > v2: address Marc Zyngier's comments: > > https://lists.gnu.org/archive/html/qemu-devel/2025-01/msg03451.html > > --- [...] > > +Live migration and PAuth > > +~~~~~~~~~~~~~~~~~~~~~~~~ > > + > > +The level of PAuth support depends on which Arm architecture a given CPU > > +supports (e.g. Armv8.3 vs. Armv8.6). This gradation in PAuth support > > +has implications for live migration. For example, to be able to > > +live-migrate from host-A (with Armv8.3) to host-B (with Arm v8.6): > > + > > + - the source and destination hosts must "agree" on (a) the PAC > > + signature algorithm, and (b) all the sub-features of PAuth; or > > + > > + - the alternative (and less desirable) option is to turn off PAuth > > + off on both source and destination — this is generally not > > + recommended, as PAuth is a security feature. > > + > > +TCG > > +--- > > > > -TCG vCPU features are CPU features that are specific to TCG. > > -Below is the list of TCG vCPU features and their descriptions. > > The resulting header layout seems weird to me. > Initially we had at top level (assuming ===): > > KVM vCPU Features > TCG vCPU Features > SVE CPU Properties > SME CPU Properties > RME CPU Properties > > and now > > TCG vCPU Features has somehow disappeared giving the impression that > there are none. I did think about it :) That's why I wrote this in the cover-letter; not sure if you noticed it: I replaced the "TCG vCPU Features" heading with "PAuth" because of this: before this change, the section says, it is about "CPU features that are specific to TCG". But it has only PAuth-related parameters under it. Since PAuth is relevant to both KVM and TCG, I moved them under a separate PAuth section, instead of duplicating it. But now we have a small inconsistency - there's a KVM-only CPU features section, but no TCG-only section. I thought when there are more TCG-only CPU features, that section can be added back in. Or I can add that back in, if anyone feels strongly about it. > SME and RME and TCG only if am not wrong while PAUTH and SVE are both > KVM and TCG I didn't know that. I read the docs a bit more closer about SME, RME, and SVE, and did some quick `git-annotate` analysis: - "SME is not supported by KVM at this time" — this was added in commit e74c097638 (target/arm: Add cpu properties for SME, 2022-06-20). If it is still accurate, then yes, SME looks to be TCG-only. - "The status of RME support with QEMU is experimental" — this was added in commit 57223a4c24 (docs/system/arm: Document FEAT_RME, 2023-06-22). The phrase "with QEMU" doesn't quite decisively tell me whether it is experimental for TCG-only, or if it also applies for KVM. Maybe Richard (in Cc) can tell us more. - SVE seems to be for both KVM and TCG, as the section "SVE CPU Property Dependencies and Constraints" talks about KVM. - PAuth is both KVM and TCG. > Maybe we shall > - rename KVM vCPU Features -> KVM only vCPU Features > - Add a TCG only vCPU features including both SME and RME ones > - introduce a top level KVM and TCG vCPU features with below: > PAUTH, SVE, detailing potential different semantic for both KVM and TCG mode Yeah, it can be done. Would you be okay if I do it as a follow-up? As this a re-work of the entire doc with several features. > Also while we are at it, we may use vCPU everywhere instead of CPU (SVE > CPU Properties) and just skip CPU if it lays within the KVM and TCG vCPU > Features Yes, make sense. [...]
On Tue, 18 Feb 2025 at 11:29, Kashyap Chamarthy <kchamart@redhat.com> wrote: > > (Cc: Richard Henderson; context: "SME" and "RME" feature discussion > below.) > > On Mon, Feb 17, 2025 at 06:43:01PM +0100, Eric Auger wrote: > > The resulting header layout seems weird to me. > > Initially we had at top level (assuming ===): > > > > KVM vCPU Features > > TCG vCPU Features > > SVE CPU Properties > > SME CPU Properties > > RME CPU Properties > > > > and now > > > > TCG vCPU Features has somehow disappeared giving the impression that > > there are none. > > Maybe we shall > > - rename KVM vCPU Features -> KVM only vCPU Features > > - Add a TCG only vCPU features including both SME and RME ones > > - introduce a top level KVM and TCG vCPU features with below: > > PAUTH, SVE, detailing potential different semantic for both KVM and TCG mode > > Yeah, it can be done. Would you be okay if I do it as a follow-up? As > this a re-work of the entire doc with several features. I think personally I would favour not having the split of "KVM only", "TCG only", etc sections. Instead document all of the properties in the same format, and have each property say whether it is TCG-specific, KVM-specific, etc. Some of these properties may at some point in the future change, after all -- SME is currently TCG only but may get support in KVM and HVF in future; "aarch64" is currently KVM only but we might some day support it in TCG. thanks -- PMM
Hi, On 2/18/25 12:34 PM, Peter Maydell wrote: > On Tue, 18 Feb 2025 at 11:29, Kashyap Chamarthy <kchamart@redhat.com> wrote: >> (Cc: Richard Henderson; context: "SME" and "RME" feature discussion >> below.) >> >> On Mon, Feb 17, 2025 at 06:43:01PM +0100, Eric Auger wrote: >>> The resulting header layout seems weird to me. >>> Initially we had at top level (assuming ===): >>> >>> KVM vCPU Features >>> TCG vCPU Features >>> SVE CPU Properties >>> SME CPU Properties >>> RME CPU Properties >>> >>> and now >>> >>> TCG vCPU Features has somehow disappeared giving the impression that >>> there are none. >>> Maybe we shall >>> - rename KVM vCPU Features -> KVM only vCPU Features >>> - Add a TCG only vCPU features including both SME and RME ones >>> - introduce a top level KVM and TCG vCPU features with below: >>> PAUTH, SVE, detailing potential different semantic for both KVM and TCG mode >> Yeah, it can be done. Would you be okay if I do it as a follow-up? As >> this a re-work of the entire doc with several features. > I think personally I would favour not having the split of > "KVM only", "TCG only", etc sections. Instead document > all of the properties in the same format, and have each > property say whether it is TCG-specific, KVM-specific, etc. This other alternative looks totally fine to me as well. > > Some of these properties may at some point in the future > change, after all -- SME is currently TCG only but may get > support in KVM and HVF in future; "aarch64" is currently > KVM only but we might some day support it in TCG. agreed Eric > > thanks > -- PMM >
On Tue, Feb 18, 2025 at 11:34:38AM +0000, Peter Maydell wrote: > On Tue, 18 Feb 2025 at 11:29, Kashyap Chamarthy <kchamart@redhat.com> wrote: [...] > > > Maybe we shall > > > - rename KVM vCPU Features -> KVM only vCPU Features > > > - Add a TCG only vCPU features including both SME and RME ones > > > - introduce a top level KVM and TCG vCPU features with below: > > > PAUTH, SVE, detailing potential different semantic for both KVM and TCG mode > > > > Yeah, it can be done. Would you be okay if I do it as a follow-up? As > > this a re-work of the entire doc with several features. > > I think personally I would favour not having the split of > "KVM only", "TCG only", etc sections. Instead document > all of the properties in the same format, and have each > property say whether it is TCG-specific, KVM-specific, etc. > > Some of these properties may at some point in the future > change, after all -- SME is currently TCG only but may get > support in KVM and HVF in future; "aarch64" is currently > KVM only but we might some day support it in TCG. I agree. As the PAuth case demonstrated, it only makes sense to entirely do away with KVM- and TCG-specific sections and use a consistent format througout. That way, no need to remember to update outdated sections. It's also consistent with the x86 docs[1], where we don't draw attention to KVM- or TCG-specific features. I can rework the doc and send a follow-up. (Eric: I assume you're also fine with Peter's suggestion above :)) [1] https://www.qemu.org/docs/master/system/i386/cpu.html
diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst index a596316384..94d260b573 100644 --- a/docs/system/arm/cpu-features.rst +++ b/docs/system/arm/cpu-features.rst @@ -204,11 +204,49 @@ the list of KVM vCPU features and their descriptions. the guest scheduler behavior and/or be exposed to the guest userspace. -TCG vCPU Features -================= +"PAuth" (Pointer Authentication) +================================ + +PAuth (Pointer Authentication) is a security feature in software that +was introduced in Armv8.3-A. It aims to protect against ROP +(return-oriented programming) attacks. + +KVM +--- + +``pauth`` + + Enable or disable ``FEAT_Pauth``. No other properties can be + controlled. + + The host CPU will define the PAC (pointer authentication + code) cryptographic algorithm. + + There are different "levels" of PAuth support. The host CPU + definition will define that level (e.g. PAuth, EPAC, PAuth2, FPAC, + FPACCOMBINE, etc). Refer to the Arm architecture extension documents + for details about the description of these features. + +Live migration and PAuth +~~~~~~~~~~~~~~~~~~~~~~~~ + +The level of PAuth support depends on which Arm architecture a given CPU +supports (e.g. Armv8.3 vs. Armv8.6). This gradation in PAuth support +has implications for live migration. For example, to be able to +live-migrate from host-A (with Armv8.3) to host-B (with Arm v8.6): + + - the source and destination hosts must "agree" on (a) the PAC + signature algorithm, and (b) all the sub-features of PAuth; or + + - the alternative (and less desirable) option is to turn off PAuth + off on both source and destination — this is generally not + recommended, as PAuth is a security feature. + +TCG +--- -TCG vCPU features are CPU features that are specific to TCG. -Below is the list of TCG vCPU features and their descriptions. +For TCG, along with ``pauth``, it is possible to control a few other +properties of PAuth: ``pauth`` Enable or disable ``FEAT_Pauth`` entirely.
PAuth (Pointer Authentication), a security feature in software, is relevant for both KVM and QEMU. Relect this fact into the docs: - For KVM, `pauth` is a binary, "on" vs "off" option. The host CPU will choose the cryptographic algorithm. - For TCG, however, along with `pauth`, a couple of properties can be controlled -- they're are related to cryptographic algorithm choice. Thanks to Peter Maydell and Marc Zyngier for explaining more about PAuth on IRC (#qemu, OFTC). Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> --- v2: address Marc Zyngier's comments: https://lists.gnu.org/archive/html/qemu-devel/2025-01/msg03451.html --- docs/system/arm/cpu-features.rst | 46 +++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 4 deletions(-)