From: Nicholas Piggin <npiggin@gmail.com>
To: Christophe Leroy <christophe.leroy@c-s.fr>,
linuxppc-dev@lists.ozlabs.org
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org
Subject: Re: [PATCH v2 1/4] powerpc/64s: implement probe_kernel_read/write without touching AMR
Date: Fri, 03 Apr 2020 21:05:26 +1000 [thread overview]
Message-ID: <1585911072.njtr9qmios.astroid@bobo.none> (raw)
In-Reply-To: <558b6131-60b4-98b7-dc40-25d8dacea05a@c-s.fr>
Christophe Leroy's on April 3, 2020 8:31 pm:
>
>
> Le 03/04/2020 à 11:35, Nicholas Piggin a écrit :
>> There is no need to allow user accesses when probing kernel addresses.
>
> I just discovered the following commit
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75a1a607bb7e6d918be3aca11ec2214a275392f4
>
> This commit adds probe_kernel_read_strict() and probe_kernel_write_strict().
>
> When reading the commit log, I understand that probe_kernel_read() may
> be used to access some user memory. Which will not work anymore with
> your patch.
Hmm, I looked at _strict but obviously not hard enough. Good catch.
I don't think probe_kernel_read() should ever access user memory,
the comment certainly says it doesn't, but that patch sort of implies
that they do.
I think it's wrong. The non-_strict maybe could return userspace data to
you if you did pass a user address? I don't see why that shouldn't just
be disallowed always though.
And if the _strict version is required to be safe, then it seems like a
bug or security issue to just allow everyone that doesn't explicitly
override it to use the default implementation.
Also, the way the weak linkage is done in that patch, means parisc and
um archs that were previously overriding probe_kernel_read() now get
the default probe_kernel_read_strict(), which would be wrong for them.
>
> Isn't it probe_kernel_read_strict() and probe_kernel_write_strict() that
> you want to add ?
>
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> v2:
>> - Enable for all powerpc (suggested by Christophe)
>> - Fold helper function together (Christophe)
>> - Rename uaccess.c to maccess.c to match kernel/maccess.c.
>>
>> arch/powerpc/include/asm/uaccess.h | 25 +++++++++++++++-------
>> arch/powerpc/lib/Makefile | 2 +-
>> arch/powerpc/lib/maccess.c | 34 ++++++++++++++++++++++++++++++
>
> x86 does it in mm/maccess.c
Yeah I'll fix that up, thanks.
Thanks,
Nick
next parent reply other threads:[~2020-04-03 11:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200403093529.43587-1-npiggin@gmail.com>
[not found] ` <558b6131-60b4-98b7-dc40-25d8dacea05a@c-s.fr>
2020-04-03 11:05 ` Nicholas Piggin [this message]
2020-04-07 4:01 ` [PATCH v2 1/4] powerpc/64s: implement probe_kernel_read/write without touching AMR Nicholas Piggin
2020-04-07 9:09 ` Daniel Borkmann
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=1585911072.njtr9qmios.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=ast@kernel.org \
--cc=christophe.leroy@c-s.fr \
--cc=daniel@iogearbox.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhiramat@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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