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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f8730d2d-41bf-407a-b44b-6cb9c1e5d4b3@arm.com>
Date: Wed, 18 Jun 2025 16:58:56 +0530
From: Dev Jain <dev.jain@....com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.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 18/06/25 4:52 pm, Lorenzo Stoakes wrote:
> 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?

MAP_CHUNK_SIZE was chosen randomly. Good to see it translates into something logical : )

So I guess I am correct, if we can find two VMAs (except at the edge of the high addr boundary)
with a gap of greater than MAP_CHUNK_SIZE then there is a bug in mmap().

>
> 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.