linux-kernel - Re: [PATCH] mm/mprotect: Fix maple tree start address in do_mprotect

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] [day] [month] [year] [list]

Message-ID: <20220826032728.c5zw3bh4pmbz66dp@revolver>
Date:   Fri, 26 Aug 2022 03:27:34 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>, Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH] mm/mprotect: Fix maple tree start address in
 do_mprotect_pkey()

* Andrew Morton <akpm@...ux-foundation.org> [220825 21:06]:
> On Thu, 25 Aug 2022 20:30:24 +0000 Liam Howlett <liam.howlett@...cle.com> wrote:
> 
> > Use the untagged_addr() instead of the address passed into the function.
> 
> What are the runtime effects of this fix?

Prior to my change to use the maple tree, the start address was changed
before calling find_vma() with the untagged_addr() version of start.  My
first change recorded the tagged address and searched on the incorrect
start location - which would have found the incorrect VMA.  This fix
will use the untagged_addr() as the start of the search as it was
before I changed the code at all.

Any penalty of calling untagged_addr() occurred regardless of the
version that was used.  The search of the maple tree would have also
occurred in both versions - just at the wrong location before this fix.
I expect that the execution time would be equal as the search on the
tagged address would have either returned a VMA at start, or the VMA in
the next slot in the maple tree node - probably immeasurably slower
since the data is very likely already in the CPU cache, but I don't have
hard data to say either way.  I can look into a benchmark to measure the
difference between both working versions, but I don't have an arm64
native target so it will be emulated.