linux-kernel - Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <57966497-d21c-5439-e4ba-d75f5552282f@linaro.org>
Date:   Sun, 9 Dec 2018 08:53:19 -0600
From:   Richard Henderson <richard.henderson@...aro.org>
To:     Kristina Martsenko <kristina.martsenko@....com>,
        linux-arm-kernel@...ts.infradead.org
Cc:     Adam Wallis <awallis@...eaurora.org>,
        Amit Kachhap <amit.kachhap@....com>,
        Andrew Jones <drjones@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Christoffer Dall <christoffer.dall@....com>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave P Martin <dave.martin@....com>,
        Jacob Bramley <jacob.bramley@....com>,
        Kees Cook <keescook@...omium.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Mark Rutland <mark.rutland@....com>,
        Ramana Radhakrishnan <ramana.radhakrishnan@....com>,
        Suzuki K Poulose <suzuki.poulose@....com>,
        Will Deacon <will.deacon@....com>,
        kvmarm@...ts.cs.columbia.edu, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 04/13] arm64/kvm: hide ptrauth from guests

On 12/7/18 12:39 PM, Kristina Martsenko wrote:
> From: Mark Rutland <mark.rutland@....com>
> 
> In subsequent patches we're going to expose ptrauth to the host kernel
> and userspace, but things are a bit trickier for guest kernels. For the
> time being, let's hide ptrauth from KVM guests.
> 
> Regardless of how well-behaved the guest kernel is, guest userspace
> could attempt to use ptrauth instructions, triggering a trap to EL2,
> resulting in noise from kvm_handle_unknown_ec(). So let's write up a
> handler for the PAC trap, which silently injects an UNDEF into the
> guest, as if the feature were really missing.

Reviewing the long thread that accompanied v5, I thought we were *not* going to
trap PAuth instructions from the guest.

In particular, the OS distribution may legitimately be built to include
hint-space nops.  This includes XPACLRI, which is used by the C++ exception
unwinder and not controlled by SCTLR_EL1.EnI{A,B}.

It seems like the header comment here, and

> +/*
> + * Guest usage of a ptrauth instruction (which the guest EL1 did not turn into
> + * a NOP).
> + */
> +static int kvm_handle_ptrauth(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +

here, need updating.


r~