From: Andrew Scull <ascull@google.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: kvm@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH v2 5/5] KVM: arm64: Simplify PtrAuth alternative patching
Date: Mon, 22 Jun 2020 11:39:32 +0100 [thread overview]
Message-ID: <20200622103932.GA178085@google.com> (raw)
In-Reply-To: <20200622091508.GB88608@C02TD0UTHF1T.local>
On Mon, Jun 22, 2020 at 10:15:08AM +0100, Mark Rutland wrote:
> On Mon, Jun 22, 2020 at 09:06:43AM +0100, Marc Zyngier wrote:
> > --- a/arch/arm64/include/asm/kvm_ptrauth.h
> > +++ b/arch/arm64/include/asm/kvm_ptrauth.h
> > @@ -61,44 +61,36 @@
> >
> > /*
> > * Both ptrauth_switch_to_guest and ptrauth_switch_to_host macros will
> > - * check for the presence of one of the cpufeature flag
> > - * ARM64_HAS_ADDRESS_AUTH_ARCH or ARM64_HAS_ADDRESS_AUTH_IMP_DEF and
> > + * check for the presence ARM64_HAS_ADDRESS_AUTH, which is defined as
> > + * (ARM64_HAS_ADDRESS_AUTH_ARCH || ARM64_HAS_ADDRESS_AUTH_IMP_DEF) and
> > * then proceed ahead with the save/restore of Pointer Authentication
> > - * key registers.
> > + * key registers if enabled for the guest.
> > */
> > .macro ptrauth_switch_to_guest g_ctxt, reg1, reg2, reg3
> > -alternative_if ARM64_HAS_ADDRESS_AUTH_ARCH
> > +alternative_if_not ARM64_HAS_ADDRESS_AUTH
> > b 1000f
> > alternative_else_nop_endif
> > -alternative_if_not ARM64_HAS_ADDRESS_AUTH_IMP_DEF
> > - b 1001f
> > -alternative_else_nop_endif
> > -1000:
> > mrs \reg1, hcr_el2
> > and \reg1, \reg1, #(HCR_API | HCR_APK)
> > - cbz \reg1, 1001f
> > + cbz \reg1, 1000f
> > add \reg1, \g_ctxt, #CPU_APIAKEYLO_EL1
> > ptrauth_restore_state \reg1, \reg2, \reg3
> > -1001:
> > +1000:
> > .endm
>
> Since these are in macros, we could use \@ to generate a macro-specific
> lavel rather than a magic number, which would be less likely to conflict
> with the surrounding environment and would be more descriptive. We do
> that in a few places already, and here it could look something like:
>
> | alternative_if_not ARM64_HAS_ADDRESS_AUTH
> | b .L__skip_pauth_switch\@
> | alternative_else_nop_endif
> |
> | ...
> |
> | .L__skip_pauth_switch\@:
>
> Per the gas documentation
>
> | \@
> |
> | as maintains a counter of how many macros it has executed in this
> | pseudo-variable; you can copy that number to your output with ‘\@’,
> | but only within a macro definition.
Is this relibale for this sort of application? The description just
sounds like a counter of macros rather than specifically a unique label
generator. It may work most of the time but also seems that it has the
potential to be more fragile given that it would change based on the
rest of the code in the file to potentially conflict with something it
didn't previously conflict with.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2020-06-22 10:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 8:06 [PATCH v2 0/5] KVM/arm64: Enable PtrAuth on non-VHE KVM Marc Zyngier
2020-06-22 8:06 ` [PATCH v2 1/5] KVM: arm64: Enable Address Authentication at EL2 if available Marc Zyngier
2020-06-22 9:04 ` Mark Rutland
2020-06-22 8:06 ` [PATCH v2 2/5] KVM: arm64: Allow ARM64_PTR_AUTH when ARM64_VHE=n Marc Zyngier
2020-06-22 8:06 ` [PATCH v2 3/5] KVM: arm64: Allow PtrAuth to be enabled from userspace on non-VHE systems Marc Zyngier
2020-06-22 8:06 ` [PATCH v2 4/5] KVM: arm64: Check HCR_EL2 instead of shadow copy to swap PtrAuth registers Marc Zyngier
2020-06-22 8:06 ` [PATCH v2 5/5] KVM: arm64: Simplify PtrAuth alternative patching Marc Zyngier
2020-06-22 9:15 ` Mark Rutland
2020-06-22 10:25 ` Marc Zyngier
2020-06-22 10:31 ` Mark Rutland
2020-06-22 10:39 ` Andrew Scull [this message]
2020-06-22 10:43 ` Andrew Scull
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200622103932.GA178085@google.com \
--to=ascull@google.com \
--cc=Dave.Martin@arm.com \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox