Re: [PATCH v6 00/18] arm64: return address signing

From: James Morse <james.morse@arm.com>
To: Marc Zyngier <maz@kernel.org>, Amit Kachhap <amit.kachhap@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Kees Cook <keescook@chromium.org>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kristina Martsenko <kristina.martsenko@arm.com>,
	Dave Martin <Dave.Martin@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
	Vincenzo Frascino <Vincenzo.Frascino@arm.com>,
	Will Deacon <will@kernel.org>, Ard Biesheuvel <ardb@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 00/18] arm64: return address signing
Date: Thu, 12 Mar 2020 17:26:06 +0000	[thread overview]
Message-ID: <bd76de32-12c5-fcbe-25d2-c501f9491bee@arm.com> (raw)
In-Reply-To: <c5889c07a559426798ed508da5755d9e@kernel.org>

Hi Amit, Marc,

On 12/03/2020 15:05, Marc Zyngier wrote:
> On 2020-03-12 13:21, Amit Kachhap wrote:
>> On 3/12/20 6:17 PM, Marc Zyngier wrote:
>>> On 2020-03-12 08:06, Amit Kachhap wrote:
>>>> On 3/12/20 12:23 PM, Amit Kachhap wrote:
>>>>> On 3/11/20 2:58 PM, James Morse wrote:
>>>>>> On 3/6/20 6:35 AM, Amit Daniel Kachhap wrote:
>>>>>>> This series improves function return address protection for the arm64 kernel, by
>>>>>>> compiling the kernel with ARMv8.3 Pointer Authentication instructions (referred
>>>>>>> ptrauth hereafter). This should help protect the kernel against attacks using
>>>>>>> return-oriented programming.
>>>>>>
>>>>>> (as it looks like there may be another version of this:)
>>>>>>
>>>>>> Am I right in thinking that after your patch 10 changing
>>>>>> cpu_switch_to(), only the A key is live during kernel execution?
>>>>>
>>>>> Yes

>>>>>> KVM is still save/restoring 4 extra keys around guest-entry/exit. As you
>>>>>> restore all the keys on return to user-space, is this still necessary?
>>>>>
>>>>> Yes Its a good optimization to skip 4 non-A keys. I was wondering whether to do it in
>>>>> this series or send it separately.
>>>>
>>>> I suppose we can only skip non-A keys save/restore for host context. If
>>>> we skip non-A keys for guest context then guest with old implementation
>>>> will break. Let me know your opinion.
>>>
>>> I don't think you can skip anything as far as the guest is concerned.
>>> But being able to skip the B keys (which is what I expect you call the
>>> non-A keys) on the host would certainly be useful.

> But if KVM doesn't save/restore the host's B-keys in the world switch,
> then you must make sure that no host userspace can make use of them,
> as they would be the guest's keys.

Yes, the arch code entry.S changes cover this with ptrauth_keys_install_user. It restores
4 keys, and the generic key.

We always need to save/restore all the guest keys (as we do today).
But when ptrauth_restore_state restores the host keys, it only needs to restore the one
the kernel uses. (possibly using the same macro's so it stays up to date?!)

If we return to user-space, the arch code's entry code does the right thing.
KVM's user-space peeking at the keys will see the saved values.

My original question was more around: do we need to do this now, or can we clean it up in
a later kernel version?

(and a sanity check that it doesn't lead to a correctness problem)

Thanks,

James

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel