linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Shuah Khan" <shuah@kernel.org>, "Dev Jain" <dev.jain@arm.com>,
	"Thomas Gleixner" <tglx@linutronix.de>
Cc: linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	kernel test robot <oliver.sang@intel.com>
Subject: Re: [PATCH v3 4/4] selftests/mm: virtual_address_range: Avoid reading from VM_IO mappings
Date: Tue, 14 Jan 2025 11:15:28 +0100	[thread overview]
Message-ID: <c494f2b2-714e-4531-9c39-2fb9f7ebfe06@redhat.com> (raw)
In-Reply-To: <20250113-virtual_address_range-tests-v3-4-f4a8e6b7feed@linutronix.de>

On 13.01.25 14:15, Thomas Weißschuh wrote:
> The virtual_address_range selftest reads from the start of each mapping
> listed in /proc/self/maps.
> However not all mappings are valid to be arbitrarily accessed.
> 
> For example the vvar data used for virtual clocks on x86 [vvar_vclock]
> can only be accessed if 1) the kernel configuration enables virtual
> clocks and 2) the hypervisor provided the data for it.
> Only the VDSO itself has the necessary information to know this.
> Since commit e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping")
> the virtual clock data was split out into its own mapping, leading
> to EFAULT from read() during the validation.
> 
> Check for the VM_IO flag as a proxy.
> It is present for the VVAR mappings and MMIO ranges can be dangerous to
> access arbitrarily.
> 
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Closes: https://lore.kernel.org/oe-lkp/202412271148.2656e485-lkp@intel.com
> Fixes: e93d2521b27f ("x86/vdso: Split virtual clock pages into dedicated mapping")
> Fixes: 010409649885 ("selftests/mm: confirm VA exhaustion without reliance on correctness of mmap()")
> Suggested-by: David Hildenbrand <david@redhat.com>
> Link: https://lore.kernel.org/lkml/e97c2a5d-c815-4936-a767-ac42a3220a90@redhat.com/
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 
> Revert "selftests/mm: virtual_address_range: Avoid reading VVAR mappings"
> 
> This reverts commit 05cc5d292ac4238684b59922aecf59c932edefa0.
> ---
>   tools/testing/selftests/mm/virtual_address_range.c |  4 ++++
>   tools/testing/selftests/mm/vm_util.c               | 21 +++++++++++++++++++++
>   tools/testing/selftests/mm/vm_util.h               |  1 +
>   3 files changed, 26 insertions(+)
> 
> diff --git a/tools/testing/selftests/mm/virtual_address_range.c b/tools/testing/selftests/mm/virtual_address_range.c
> index 386e4e46fa65b98af78dee4bb30144eb2b51f528..b380e102b22f0a44654ab046f257e8c35e8d90e9 100644
> --- a/tools/testing/selftests/mm/virtual_address_range.c
> +++ b/tools/testing/selftests/mm/virtual_address_range.c
> @@ -15,6 +15,7 @@
>   #include <sys/time.h>
>   #include <fcntl.h>
>   
> +#include "vm_util.h"
>   #include "../kselftest.h"
>   
>   /*
> @@ -159,6 +160,9 @@ static int validate_complete_va_space(void)
>   		if (prot[0] != 'r')
>   			continue;
>   
> +		if (check_vmflag_io((void *)start_addr))
> +			continue;
> +
>   		/*
>   		 * Confirm whether MAP_CHUNK_SIZE chunk can be found or not.
>   		 * If write succeeds, no need to check MAP_CHUNK_SIZE - 1
> diff --git a/tools/testing/selftests/mm/vm_util.c b/tools/testing/selftests/mm/vm_util.c
> index 8468a19d6acca10c7e9228c03a935cdeb2402b5d..161fe03b07af78244efc669a36155ad603fa6f7d 100644
> --- a/tools/testing/selftests/mm/vm_util.c
> +++ b/tools/testing/selftests/mm/vm_util.c
> @@ -400,3 +400,24 @@ unsigned long get_free_hugepages(void)
>   	fclose(f);
>   	return fhp;
>   }
> +
> +bool check_vmflag_io(void *addr)

Interestingly, this will only work if addr really is the start of the 
mapping, as __get_smap_entry() cannot handle "address falls into a 
mapping". Good enough for now, but might be worth a comment.

(wrong usage would fail with  No VmFlags for ... )

> +{
> +	char *saveptr, *flag, *strtok_arg;

" On some implementations, *saveptr is required to be NULL on the first 
call to strtok_r() that is being used to parse str."

Maybe just initialize it to NULL.

> +	char buffer[MAX_LINE_LENGTH];
> +
> +	strtok_arg = __get_smap_entry(addr, "VmFlags:", buffer, sizeof(buffer));
> +	if (!strtok_arg)
> +		ksft_exit_fail_msg("%s: No VmFlags for %p\n", __func__, addr);
> +
> +	while (true) {
> +		flag = strtok_r(strtok_arg, " ", &saveptr);
> +		if (!flag)
> +			break;
> +		if (strcmp(flag, "io") == 0)
> +			return true;

Are these early exit allowed with strtok_r()?

An alternative seems to be using strcspn() that doesn't modify 
strings/maintain state in-between calls.

-- 
Cheers,

David / dhildenb



      parent reply	other threads:[~2025-01-14 10:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 13:15 [PATCH v3 0/4] selftests/mm: virtual_address_range: Reduce memory usage and avoid VM_IO access Thomas Weißschuh
2025-01-13 13:15 ` [PATCH v3 1/4] selftests/mm: virtual_address_range: mmap() without PROT_WRITE Thomas Weißschuh
2025-01-13 15:46   ` Dev Jain
2025-01-13 13:15 ` [PATCH v3 2/4] selftests/mm: virtual_address_range: Unmap chunks after validation Thomas Weißschuh
2025-01-14 13:11   ` David Hildenbrand
2025-01-13 13:15 ` [PATCH v3 3/4] selftests/mm: vm_util: Split up /proc/self/smaps parsing Thomas Weißschuh
2025-01-14 10:01   ` David Hildenbrand
2025-01-13 13:15 ` [PATCH v3 4/4] selftests/mm: virtual_address_range: Avoid reading from VM_IO mappings Thomas Weißschuh
2025-01-14  1:25   ` Andrew Morton
2025-01-14 10:15   ` David Hildenbrand [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c494f2b2-714e-4531-9c39-2fb9f7ebfe06@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dev.jain@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=oliver.sang@intel.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.weissschuh@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox