linux-kernel - Re: [PATCH v2 0/6] arm64/signal: Signal handling cleanups

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: <20230131153816.GA2646@willie-the-truck>
Date:   Tue, 31 Jan 2023 15:38:16 +0000
From:   Will Deacon <will@...nel.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Mark Brown <broonie@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/6] arm64/signal: Signal handling cleanups

On Tue, Jan 31, 2023 at 12:51:33PM +0000, Catalin Marinas wrote:
> Hi Mark,
> 
> On Tue, Jan 03, 2023 at 08:25:15PM +0000, Mark Brown wrote:
> > This series collects a number of small cleanups to the signal handling
> > code which removes redundant validation of size information and avoids
> > reading the same data from userspace twice.
> > 
> > There are some overlaps with both the TPIDR2 signal handling and SME2
> > serieses which are also in flight, applying this will require
> > adjustments in those serieses and vice versa.
> [...]
> > Mark Brown (6):
> >       arm64/signal: Don't redundantly verify FPSIMD magic
> >       arm64/signal: Remove redundant size validation from parse_user_sigframe()
> >       arm64/signal: Make interface for restore_fpsimd_context() consistent
> 
> I'm fine with the first three patches, they seem correct and make the
> frame checking more consistent.
> 
> >       arm64/signal: Avoid rereading context frame sizes
> >       arm64/signal: Only read new data when parsing the SVE context
> >       arm64/signal: Only read new data when parsing the ZA context
> 
> I'm not sure these add much to the code readability (and the performance
> improvement I guess is negligible). We avoid some copy_from_user() into
> the context structures but rely on data read previously or some
> get_user() into local variables. Personally I'd make the
> restore_fpsimd_context() also do a copy_from_user() for consistency with
> the current sve and za frames restoring.
> 
> Personal preference, not sure whether Will has the same view.

That main thing I'm worried about is the potential for ToCToU bugs if we
read userdata more than once. For example, if we end up splitting checks
between the two reads, then an attacker could update the value in the
middle and potential cause us issues. If we just read the stuff once, we
don't have to worry about that.

Will