linux-kernel - Re: [PATCH v15 2/4] syscall user dispatch: untag selector addresses before access

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: <ZC1UEK43yOsXKvi4@arm.com>
Date:   Wed, 5 Apr 2023 11:57:20 +0100
From:   Catalin Marinas <catalin.marinas@....com>
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Gregory Price <gourry.memverge@...il.com>,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-arch@...r.kernel.org, avagin@...il.com, peterz@...radead.org,
        luto@...nel.org, krisman@...labora.com, tglx@...utronix.de,
        corbet@....net, shuah@...nel.org, arnd@...db.de,
        Gregory Price <gregory.price@...verge.com>
Subject: Re: [PATCH v15 2/4] syscall user dispatch: untag selector addresses
 before access_ok

On Tue, Apr 04, 2023 at 06:33:40PM +0100, Catalin Marinas wrote:
> On Tue, Apr 04, 2023 at 12:45:06PM +0200, Oleg Nesterov wrote:
> > doesn't this mean that access_ok() on arm64 could use
> > untagged_addr(addr) unconditionally without any security risk?
> 
> Yes, from the security perspective, but there are ABI implications.
> 
> Currently untagged_addr() in access_ok() is conditional on the user
> process enabling the tagged address ABI (prctl() that sets a TIF flag).
> The reason we did not enable this by default was a slight fear of
> breaking the ABI since tagged pointers were not allowed at the syscall
> boundary. It turned out that the fear was justified since the
> unconditional untagged_addr() in brk() broke user space (see commit
> dcde237319e6 "mm: Avoid creating virtual address aliases in
> brk()/mmap()/mremap()"; the user was doing an sbrk(PY_SSIZE_T_MAX) and
> bits 56 and higher were ignored by the kernel).
> 
> I'd be ok with untagging the address unconditionally in the arm64
> access_ok() introduce another unaliased_access_ok() (I'm not good at
> naming functions) that preserves the non-tagged behaviour and we use it
> in brk/mmap/mremap().

Actually, I'm wrong here. There's no access_ok() check on the brk()
path. The unconditional untagged_addr() prior to dcde237319e6 messed up
the comparison between the old and new brk limit and shrank the heap
space for a process.

So, relaxing access_ok() to always do the untagging should not affect
the brk/mmap/mremap() cases.

-- 
Catalin