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

From: Marc Zyngier <maz@kernel.org>
To: James Morse <james.morse@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>,
	Amit Kachhap <amit.kachhap@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:31:36 +0000	[thread overview]
Message-ID: <87945e6110511caaceeb3f1294b6f88f@kernel.org> (raw)
In-Reply-To: <bd76de32-12c5-fcbe-25d2-c501f9491bee@arm.com>

Hi James,

On 2020-03-12 17:26, James Morse wrote:
> 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)

I think what we have now is sane, and doesn't seem to lead to any
issue (at least that I can see). We can always optimize this at a
later point.

Thanks,

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

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