From: Dylan Hatch <dylanbhatch@google.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] selftests/proc: Fix proc-pid-vm for vsyscall=xonly.
Date: Fri, 17 Jun 2022 11:45:43 -0700 [thread overview]
Message-ID: <CADBMgpwt2ALzBTtEm7v6DLL_9pjUhVLDpBLHXn1b0bvVf2BSvg@mail.gmail.com> (raw)
In-Reply-To: <941e0991-eb3e-f988-8262-3d51ff8badad@linuxfoundation.org>
On Thu, Jun 16, 2022 at 4:01 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> On 6/16/22 3:10 PM, Dylan Hatch wrote:
> > This test would erroneously fail the /proc/$PID/maps case if
> > vsyscall=xonly since the existing probe of the vsyscall page only
> > succeeds if the process has read permissions. Fix this by checking for
> > either no vsyscall mapping OR an execute-only vsyscall mapping in the
> > case were probing the vsyscall page segfaults.
> >
>
> Does this fix include skipping the test with a clear message that
> says why test is skipped?
>
> > Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> > ---
> > tools/testing/selftests/proc/proc-pid-vm.c | 20 +++++++++++++++-----
> > 1 file changed, 15 insertions(+), 5 deletions(-)
> >
> > diff --git a/tools/testing/selftests/proc/proc-pid-vm.c b/tools/testing/selftests/proc/proc-pid-vm.c
> > index 28604c9f805c..5ca85520131f 100644
> > --- a/tools/testing/selftests/proc/proc-pid-vm.c
> > +++ b/tools/testing/selftests/proc/proc-pid-vm.c
> > @@ -213,9 +213,12 @@ static int make_exe(const uint8_t *payload, size_t len)
> >
> > static bool g_vsyscall = false;
> >
> > -static const char str_vsyscall[] =
> > +static const char str_vsyscall_rx[] =
> > "ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]\n";
> >
> > +static const char str_vsyscall_x[] =
> > +"ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]\n";
> > +
> > #ifdef __x86_64__
> > static void sigaction_SIGSEGV(int _, siginfo_t *__, void *___)
> > {
> > @@ -261,6 +264,7 @@ int main(void)
> > int exec_fd;
> >
> > vsyscall();
> > + const char *str_vsyscall = g_vsyscall ? str_vsyscall_rx : str_vsyscall_x;
> >
> > atexit(ate);
> >
> > @@ -314,7 +318,8 @@ int main(void)
> >
> > /* Test /proc/$PID/maps */
> > {
> > - const size_t len = strlen(buf0) + (g_vsyscall ? strlen(str_vsyscall) : 0);
> > + const size_t len_buf0 = strlen(buf0);
> > + const size_t len_vsys = strlen(str_vsyscall);
> > char buf[256];
> > ssize_t rv;
> > int fd;
> > @@ -325,11 +330,16 @@ int main(void)
> > return 1;
> > }
> > rv = read(fd, buf, sizeof(buf));
> > - assert(rv == len);
> > - assert(memcmp(buf, buf0, strlen(buf0)) == 0);
> > if (g_vsyscall) {
> > - assert(memcmp(buf + strlen(buf0), str_vsyscall, strlen(str_vsyscall)) == 0);
> > + assert(rv == len_buf0 + len_vsys);
> > + } else {
> > + /* If vsyscall isn't readable, it's either x-only or not mapped at all */
> > + assert(rv == len_buf0 + len_vsys || rv == len_buf0);
> > }
> > + assert(memcmp(buf, buf0, len_buf0) == 0);
> > + /* Check for vsyscall mapping if buf is long enough */
> > + if (rv == len_buf0 + len_vsys)
> > + assert(memcmp(buf + len_buf0, str_vsyscall, len_vsys) == 0);
> > }
> >
> > /* Test /proc/$PID/smaps */
> >
>
> The change looks good to me. Doesn't look like it skips the test though?
Instead of skipping the test, it changes the passing condition to
accept both cases of an unmapped vsyscall page and an x-only vsyscall
page. Differentiating between these two cases without relying on
/proc/$PID/maps would involve both checking the kernel command line
for vsyscall=xonly and having a special ifdef block for
CONFIG_VSYSCALL_XONLY, so accepting both as passing conditions seems
like a simpler solution.
Thanks,
Dylan
next prev parent reply other threads:[~2022-06-17 18:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 21:10 [PATCH] selftests/proc: Fix proc-pid-vm for vsyscall=xonly Dylan Hatch
2022-06-16 23:01 ` Shuah Khan
2022-06-17 18:45 ` Dylan Hatch [this message]
2022-06-17 19:38 ` Shuah Khan
2022-06-17 22:05 ` Dylan Hatch
2022-06-17 22:27 ` Shuah Khan
2022-06-22 0:18 ` Dylan Hatch
2022-06-22 17:15 ` Shuah Khan
[not found] ` <CADBMgpz3z_hB_5BVVD5-4r3qYCVc_p_SrYKZLwaLg9Fy+h2p6g@mail.gmail.com>
2022-07-11 23:15 ` Dylan Hatch
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=CADBMgpwt2ALzBTtEm7v6DLL_9pjUhVLDpBLHXn1b0bvVf2BSvg@mail.gmail.com \
--to=dylanbhatch@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
/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;
as well as URLs for NNTP newsgroup(s).