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