linux-kernel - Re: [PATCH v5 11/17] arm64: docs: document pointer authentication

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: <d73e8824-bb8e-8172-4541-9be136453020@redhat.com>
Date:   Fri, 2 Nov 2018 02:02:03 -0400
From:   Jon Masters <jcm@...hat.com>
To:     Will Deacon <will.deacon@....com>,
        Catalin Marinas <catalin.marinas@....com>
Cc:     Kristina Martsenko <kristina.martsenko@....com>,
        Mark Rutland <Mark.Rutland@....com>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        Andrew Jones <drjones@...hat.com>,
        Jacob Bramley <Jacob.Bramley@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Marc Zyngier <Marc.Zyngier@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Adam Wallis <awallis@...eaurora.org>,
        Suzuki Poulose <Suzuki.Poulose@....com>,
        Christoffer Dall <Christoffer.Dall@....com>,
        Dave P Martin <Dave.Martin@....com>,
        Amit Kachhap <Amit.Kachhap@....com>,
        Ramana Radhakrishnan <ramana.radhakrishnan@...s.arm.com>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v5 11/17] arm64: docs: document pointer authentication

On 10/19/18 1:45 PM, Will Deacon wrote:

>>> I think an alternative solution is to just disable trapping of pointer
>>> auth instructions in KVM. This will mean that the instructions will
>>> behave the same in the guest as they do in the host. HINT-space
>>> instructions (including XPACLRI) will behave as NOPs (or perform their
>>> function, if enabled by the guest), and will not trap.
>>
>> OK, so this means disabling the trap (during early EL2 setup) but still
>> sanitizing the CPUID not to report the feature to EL1 unless fully
>> supported on all CPUs.
> 
> ... which is perfectly sensible, but not actually my main concern here.
> I'm worried about the possibility of distributions shipping *now* with
> userspace that's built with these instructions. That stuff is going to
> break if/when it encounters v8.3 hardware, and I don't think we can do
> much about it other than alert them to the potential issue.

FYI tracking this for RHEL. It's not a problem currently. I'll alert our
tools teams to hold off on any PAC work until this is figured out.

Jon.

-- 
Computer Architect | Sent with my Fedora powered laptop