From: Kees Cook <keescook@chromium.org>
To: Russell Currey <ruscur@russell.cc>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>,
mpe@ellerman.id.au, linux-kernel@vger.kernel.org, dja@axtens.net,
kernel-hardening@lists.openwall.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] lkdtm: Test KUAP directional user access unlocks on powerpc
Date: Sat, 1 Feb 2020 08:40:34 -0800 [thread overview]
Message-ID: <202002010836.76B19684@keescook> (raw)
In-Reply-To: <0b016861756cbe27e66651b5c21229a06558cb57.camel@russell.cc>
On Fri, Jan 31, 2020 at 05:53:14PM +1100, Russell Currey wrote:
> Correct, the ACCESS_USERSPACE test does the same thing. Splitting this
> into separate R and W tests makes sense, even if it is unlikely that
> one would be broken without the other.
That would be my preference too -- the reason it wasn't separated before
was because it was one big toggle before. I just had both directions in
the test out of a desire for completeness.
Splitting into WRITE_USERSPACE and READ_USERSPACE seems good. Though if
you want to test functionality (read while only write disabled), then
I'm not sure what that should look like. Does the new
user_access_begin() API provide a way to query existing state? I'll go
read the series...
--
Kees Cook
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Russell Currey <ruscur@russell.cc>
Cc: kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
dja@axtens.net
Subject: Re: [PATCH] lkdtm: Test KUAP directional user access unlocks on powerpc
Date: Sat, 1 Feb 2020 08:40:34 -0800 [thread overview]
Message-ID: <202002010836.76B19684@keescook> (raw)
In-Reply-To: <0b016861756cbe27e66651b5c21229a06558cb57.camel@russell.cc>
On Fri, Jan 31, 2020 at 05:53:14PM +1100, Russell Currey wrote:
> Correct, the ACCESS_USERSPACE test does the same thing. Splitting this
> into separate R and W tests makes sense, even if it is unlikely that
> one would be broken without the other.
That would be my preference too -- the reason it wasn't separated before
was because it was one big toggle before. I just had both directions in
the test out of a desire for completeness.
Splitting into WRITE_USERSPACE and READ_USERSPACE seems good. Though if
you want to test functionality (read while only write disabled), then
I'm not sure what that should look like. Does the new
user_access_begin() API provide a way to query existing state? I'll go
read the series...
--
Kees Cook
next prev parent reply other threads:[~2020-02-01 16:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-31 5:31 [PATCH] lkdtm: Test KUAP directional user access unlocks on powerpc Russell Currey
2020-01-31 5:31 ` Russell Currey
2020-01-31 6:44 ` Christophe Leroy
2020-01-31 6:44 ` Christophe Leroy
2020-01-31 6:53 ` Russell Currey
2020-01-31 6:53 ` Russell Currey
2020-01-31 6:58 ` Christophe Leroy
2020-01-31 6:58 ` Christophe Leroy
2020-01-31 7:01 ` Russell Currey
2020-01-31 7:01 ` Russell Currey
2020-02-01 16:40 ` Kees Cook [this message]
2020-02-01 16:40 ` Kees Cook
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=202002010836.76B19684@keescook \
--to=keescook@chromium.org \
--cc=christophe.leroy@c-s.fr \
--cc=dja@axtens.net \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=ruscur@russell.cc \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.