linux-kernel - Re: [PATCH v4 09/14] selftests: harness: Move teardown conditional into test metadata

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: <20250611235117.GR543171@nvidia.com>
Date: Wed, 11 Jun 2025 20:51:17 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
	Shuah Khan <shuah@...nel.org>,
	Shuah Khan <skhan@...uxfoundation.org>, Willy Tarreau <w@....eu>,
	Thomas Weißschuh <linux@...ssschuh.net>,
	Kees Cook <kees@...nel.org>, Andy Lutomirski <luto@...capital.net>,
	Will Drewry <wad@...omium.org>, Mark Brown <broonie@...nel.org>,
	Muhammad Usama Anjum <usama.anjum@...labora.com>,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v4 09/14] selftests: harness: Move teardown conditional
 into test metadata

On Wed, Jun 11, 2025 at 04:43:00PM -0700, Nicolin Chen wrote:
> So, the test case sets an alignment with HUGEPAGE_SIZE=512MB while
> allocating buffer_size=64MB:
> 	rc = posix_memalign(&self->buffer, HUGEPAGE_SIZE, variant->buffer_size);
> 	vrc = mmap(self->buffer, variant->buffer_size, PROT_READ | PROT_WRITE,
> this gives the self->buffer a location that is 512MB aligned, but
> only mmap part of one 512MB huge page.
> 
> On the other hand, _metadata->no_teardown was mmap() outside the
> range of the [self->buffer, self->buffer + 64MB), but within the
> range of [self->buffer, self->buffer + 512MB).
> 
> E.g.
>    _metadata->no_teardown = 0xfffbfc610000 // inside range2 below
>    buffer=[0xfffbe0000000, fffbe4000000) // range1
>    buffer=[0xfffbe0000000, fffc00000000) // range2
> 
> Then ,the "vrc = mmap(..." overwrites the _metadata->no_teardown
> location to NULL..
> 
> The following change can fix, though it feels odd that the buffer
> has to be preserved with the entire huge page:
> ---------------------------------------------------------------
> @@ -2024,3 +2027,4 @@ FIXTURE_SETUP(iommufd_dirty_tracking)
> 
> -       rc = posix_memalign(&self->buffer, HUGEPAGE_SIZE, variant->buffer_size);
> +       rc = posix_memalign(&self->buffer, HUGEPAGE_SIZE,
> +                           __ALIGN_KERNEL(variant->buffer_size, HUGEPAGE_SIZE));
>         if (rc || !self->buffer) {
> ---------------------------------------------------------------
> 
> Any thought?

This seems like something, variant->buffer_size should not
be less than HUGEPAGE_SIZE I guess that is possible on 64K ARM64

But I still don't quite get it..

        rc = posix_memalign(&self->buffer, HUGEPAGE_SIZE, variant->buffer_size);

Should allocate buffer_size

        mmap_flags = MAP_SHARED | MAP_ANONYMOUS | MAP_FIXED;
                mmap_flags |= MAP_HUGETLB | MAP_POPULATE;
        vrc = mmap(self->buffer, variant->buffer_size, PROT_READ | PROT_WRITE,
                   mmap_flags, -1, 0);

Should fail if buffer_size is not a multiple of HUGEPAGE_SIZE? 

It certainly shouldn't mmap past the provided buffer_size!!!

Are you seeing the above mmap succeed and also map beyond buffer -> buffer + buffer_size?

I think that would be a kernel bug in MAP_HUGETLB!

Jason