kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Nathan Chancellor <natechancellor@gmail.com>
Cc: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org,
	James Morse <james.morse@arm.com>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Will Deacon <will@kernel.org>,
	kernel-team@android.com,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions
Date: Thu, 23 Jul 2020 09:17:15 +0100	[thread overview]
Message-ID: <0fab73670fa24d1c08711991133e4255@kernel.org> (raw)
In-Reply-To: <20200723025142.GA361584@ubuntu-n2-xlarge-x86>

Hi Nathan,

On 2020-07-23 03:51, Nathan Chancellor wrote:
> On Wed, Jul 22, 2020 at 05:22:31PM +0100, Marc Zyngier wrote:
>> So far, vcpu_has_ptrauth() is implemented in terms of 
>> system_supports_*_auth()
>> calls, which are declared "inline". In some specific conditions (clang
>> and SCS), the "inline" very much turns into an "out of line", which
>> leads to a fireworks when this predicate is evaluated on a non-VHE
>> system (right at the beginning of __hyp_handle_ptrauth).
>> 
>> Instead, make sure vcpu_has_ptrauth gets expanded inline by directly
>> using the cpus_have_final_cap() helpers, which are __always_inline,
>> generate much better code, and are the only thing that make sense when
>> running at EL2 on a nVHE system.
>> 
>> Fixes: 29eb5a3c57f7 ("KVM: arm64: Handle PtrAuth traps early")
>> Reported-by: Nathan Chancellor <natechancellor@gmail.com>
>> Reported-by: Nick Desaulniers <ndesaulniers@google.com>
>> Signed-off-by: Marc Zyngier <maz@kernel.org>
> 
> Thank you for the quick fix! I have booted a mainline kernel with this
> patch with Shadow Call Stack enabled and verified that using KVM no
> longer causes a panic.

Great! I'll try and ferry this to mainline  as quickly as possible.

> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
> 
> For the future, is there an easy way to tell which type of system I am
> using (nVHE or VHE)? I am new to the arm64 KVM world but it is 
> something
> that I am going to continue to test with various clang technologies now
> that I have actual hardware capable of it that can run a mainline
> kernel.

ARMv8.0 CPUs are only capable of running non-VHE. So if you have
something based on older ARM CPUs (such as A57, A72, A53, A73, A35...),
or licensee CPUs (ThunderX, XGene, EMag...), this will only run
non-VHE (the host kernel runs at EL1, while the hypervisor runs at
EL2.

 From ARMv8.1 onward, VHE is normally present, and the host kernel
can run at EL2 directly. ARM CPUs include A55, A65, A75, A76, A77,
N1, while licensee CPUs include TX2, Kunpeng 920, and probably some
more.

As pointed out by Zenghui in another email, KVM shows which mode
it is using. Even without KVM, the kernel prints very early on:

[    0.000000] CPU features: detected: Virtualization Host Extensions

Note that this is only a performance difference, and that most
features that are supported by the CPU can be used by KVM in either
mode.

Thanks again,

         M.
-- 
Jazz is not dead. It just smells funny...

  parent reply	other threads:[~2020-07-23  8:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 16:22 [PATCH] KVM: arm64: Prevent vcpu_has_ptrauth from generating OOL functions Marc Zyngier
2020-07-23  2:51 ` Nathan Chancellor
2020-07-23  3:30   ` Zenghui Yu
2020-07-23  8:17   ` Marc Zyngier [this message]
2020-07-23 15:59     ` Nathan Chancellor

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=0fab73670fa24d1c08711991133e4255@kernel.org \
    --to=maz@kernel.org \
    --cc=james.morse@arm.com \
    --cc=julien.thierry.kdev@gmail.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=natechancellor@gmail.com \
    --cc=ndesaulniers@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@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;
as well as URLs for NNTP newsgroup(s).