linux-kernel - Re: [PATCH] mm, mmap: remove vma

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

Date: Tue, 2 Apr 2024 10:28:42 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	patches@...ts.linux.dev, stable@...r.kenrel.org,
	Lorenzo Stoakes <lstoakes@...il.com>,
	"Liam R . Howlett" <Liam.Howlett@...cle.com>
Subject: Re: [PATCH] mm, mmap: remove vma_merge()

On Mon, Apr 01, 2024 at 09:26:24PM +0200, Vlastimil Babka wrote:
> With SLAB gone I was looking for what I could delete next, and then it
> dawned on me - it should be vma_merge(). It's simply an unmaintainable
> mess.
> 
> The code is extremely hard to follow. There has been a number of recent
> attempts to made it more readable, by Liam, Lorenzo and myself. Almost
> every time this only resulted in subtle embarassing bugs [1] [2] [3] [4]
> [5]. For many of the bugs the only reliable testcase we have is the rpm
> process running in the Open Build Service. Which is worrying, as that
> clearly makes vma_merge() a potential supply chain attack vector for
> planting backdoors.
> 
> Thus simply remove vma_merge() and all the related code, and adjust all
> callers to take the path as if merging was attempted and failed.
> The only downside is that there might now be more vmas and maple tree
> nodes due to no merging. To extensively validate that, I've booted the
> kernel with virtme-ng before and after the change and checked slabinfo
> for the number of active objects:
> 
> before:
> maple_node          1159
> vm_area_struct      1538
> 
> after:
> maple_node          1113
> vm_area_struct      1861
> 
> Yeah there's more vma's but interestingly, less maple tree nodes. I
> believe it's worth it. The larger number of smaller vmas could even help
> with better parallelism thanks to per-vma locking. So the conclusion is
> obvious - we should have never tried merging vmas in the first place,
> hence the tags on this patch.
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d014cd7c1c35
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c6759967826
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e7757876f25
> [4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1419430c8abb
> [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc0c8f9089c2
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

This is hilarious, stable folks will be excited :)

> Cc: <stable@...r.kenrel.org> # CVE mandatory
> Cc: Lorenzo Stoakes <lstoakes@...il.com>
> Cc: Liam R. Howlett <Liam.Howlett@...cle.com>
> Singed-off-by-one: Vlastimil Babka <vbabka@...e.cz>
>
> ---
>  mm/internal.h |   7 -
>  mm/mmap.c     | 368 +++-----------------------------------------------
>  mm/mremap.c   |  60 --------
>  3 files changed, 17 insertions(+), 418 deletions(-)

-- 
Sincerely yours,
Mike.