linux-kernel - Re: [PATCH 1/6] mm/selftests: Fix virtual_address

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

Message-ID: <159f6939-e7c8-492c-8195-b7e8787a08f1@lucifer.local>
Date: Wed, 18 Jun 2025 12:22:46 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Dev Jain <dev.jain@....com>
Cc: Aboorva Devarajan <aboorvad@...ux.ibm.com>, akpm@...ux-foundation.org,
        Liam.Howlett@...cle.com, shuah@...nel.org, pfalcato@...e.de,
        david@...hat.com, ziy@...dia.com, baolin.wang@...ux.alibaba.com,
        npache@...hat.com, ryan.roberts@....com, baohua@...nel.org,
        linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, donettom@...ux.ibm.com,
        ritesh.list@...il.com
Subject: Re: [PATCH 1/6] mm/selftests: Fix virtual_address_range test issues.

On Mon, Jun 16, 2025 at 09:57:10PM +0530, Dev Jain wrote:
>
> On 16/06/25 9:36 pm, Aboorva Devarajan wrote:
> > From: Donet Tom <donettom@...ux.ibm.com>
> > 3./proc/self/maps may not always have gaps smaller than MAP_CHUNK_SIZE.
> > The gap between the first high address mapping and the previous mapping
> > is not smaller than MAP_CHUNK_SIZE.
>
> For this, can't we just elide the check when we cross the high boundary?
> As I see it you are essentially nullifying the purpose of validate_complete_va_space;
> I had written that function so as to have an alternate way of checking VA exhaustion
> without relying on mmap correctness in a circular way.
>
> Btw @Lorenzo, validate_complete_va_space was written by me as my first patch ever for
> the Linux kernel : ) from the limited knowledge I have of VMA stuff, I guess the

:)

Mine was this utter triviality, but got me started :>)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1da1d573f67d11c2f80ffaf38d3cdd3fee97d4b

> only requirement for VMA alignment is PAGE_SIZE in this test, therefore, the only
> check required is that the gap between two VMAs should be at least MAP_CHUNK_SIZE?
> Or can such a gap still exist even when the VA has been exhausted?

VMAs are mapped at page granularity, the logic as to placement is determined by
the get unmapped area logic, for instance mm_get_unmapped_area_vmflags().

Unless a compatibility flag is set it'll be determined top-down.

I try to avoid thinking about 32-bit kernels at all so meh to all that :)

You get arch-specific stuff in arch_get_unmapped_area_topdown().

But the generic shared stuff is in vm_unmapped_area(), typically,
unmapped_area_topdown().

TL;DR, aside from arch stuff, the stack guard gap is the main additional
requirement, which puts (by default) 256 pages between an expanding stack and
the start of a new mapping. Which is 1 GB :) which maybe is why you chose this
value for MAP_CHUNK_SIZE?

For shadow stack we also have a 4 KB requirement. But only on x86-64 :)

Anyway I'm not sure there's huge value in sort of writing a test that too
closely mimics the code it is testing. Setting broad expections (which I presume
this test does) is better.