linux-kernel - Re: [PATCH] arm64/mm: Fix ttbr0 values stored in struct thread

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 15 Jun 2021 15:26:14 +0100
From:   Will Deacon <will@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Anshuman Khandual <anshuman.khandual@....com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>,
        James Morse <james.morse@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64/mm: Fix ttbr0 values stored in struct thread_info
 for software-pan

On Tue, Jun 15, 2021 at 03:25:39PM +0100, Catalin Marinas wrote:
> On Tue, Jun 15, 2021 at 03:02:58PM +0530, Anshuman Khandual wrote:
> > When using CONFIG_ARM64_SW_TTBR0_PAN, a task's thread_info::ttbr0 must be
> > the TTBR0_EL1 value used to run userspace. With 52-bit PAs, the PA must be
> > packed into the TTBR using phys_to_ttbr(), but we forget to do this in some
> > of the SW PAN code. Thus, if the value is installed into TTBR0_EL1 (as may
> > happen in the uaccess routines), this could result in UNPREDICTABLE
> > behaviour.
> > 
> > Since hardware with 52-bit PA support almost certainly has HW PAN, which
> > will be used in preference, this shouldn't be a practical issue, but let's
> > fix this for consistency.
> 
> I'm ok with fixing this for consistency. We should never hit those paths
> unless someone built hardware with 52-bit PA (8.2) but without PAN (8.1)
> and it would not be architecture compliant.
> 
> I'll leave it with Will for 5.14, it's no a fix that needs urgent
> queuing.
> 
> Reviewed-by: Catalin Marinas <catalin.marinas@....com>

Cheers, I'll pick it up.

Will