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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20210615142539.GJ26027@arm.com>
Date:   Tue, 15 Jun 2021 15:25:39 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Anshuman Khandual <anshuman.khandual@....com>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Will Deacon <will@...nel.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: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>