linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe LEROY <christophe.leroy@c-s.fr>
To: Kees Cook <keescook@chromium.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	LKML <linux-kernel@vger.kernel.org>,
	PowerPC <linuxppc-dev@lists.ozlabs.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [RFC PATCH] mm: add probe_user_read() and probe_user_address()
Date: Mon, 3 Dec 2018 18:11:11 +0100	[thread overview]
Message-ID: <a6d785e7-c01d-eb3c-89da-e960abc40c6d@c-s.fr> (raw)
In-Reply-To: <CAGXu5jJzp0v_Ox4gJcSdMVT7Rzuoy4mH-J3tPfrpeyCTi4o5YQ@mail.gmail.com>



Le 19/10/2018 à 17:42, Kees Cook a écrit :
> On Fri, Oct 19, 2018 at 8:14 AM, Christophe Leroy
> <christophe.leroy@c-s.fr> wrote:
>> In the powerpc, there are several places implementing safe
>> access to user data. This is sometimes implemented using
>> probe_kerne_address() with additional access_ok() verification,
>> sometimes with get_user() enclosed in a pagefault_disable()/enable()
>> pair, etc... :
>>      show_user_instructions()
>>      bad_stack_expansion()
>>      p9_hmi_special_emu()
>>      fsl_pci_mcheck_exception()
>>      read_user_stack_64()
>>      read_user_stack_32() on PPC64
>>      read_user_stack_32() on PPC32
>>      power_pmu_bhrb_to()
>>
>> In the same spirit as probe_kernel_read() and probe_kernel_address(),
>> this patch adds probe_user_read() and probe_user_address().
>>
>> probe_user_read() does the same as probe_kernel_read() but
>> first checks that it is really a user address.
>>
>> probe_user_address() is a shortcut to probe_user_read()
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> ---
>>   include/linux/uaccess.h | 10 ++++++++++
>>   mm/maccess.c            | 33 +++++++++++++++++++++++++++++++++
>>   2 files changed, 43 insertions(+)
>>
>> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
>> index efe79c1cdd47..fb00e3f847d7 100644
>> --- a/include/linux/uaccess.h
>> +++ b/include/linux/uaccess.h
>> @@ -266,6 +266,16 @@ extern long strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count);
>>   #define probe_kernel_address(addr, retval)             \
>>          probe_kernel_read(&retval, addr, sizeof(retval))
>>
>> +/**
>> + * probe_user_address(): safely attempt to read from a user location
>> + * @addr: address to read from
>> + * @retval: read into this variable
>> + *
>> + * Returns 0 on success, or -EFAULT.
>> + */
>> +#define probe_user_address(addr, retval)               \
>> +       probe_user_read(&(retval), addr, sizeof(retval))
>> +
>>   #ifndef user_access_begin
>>   #define user_access_begin() do { } while (0)
>>   #define user_access_end() do { } while (0)
>> diff --git a/mm/maccess.c b/mm/maccess.c
>> index ec00be51a24f..85d4a88a6917 100644
>> --- a/mm/maccess.c
>> +++ b/mm/maccess.c
>> @@ -67,6 +67,39 @@ long __probe_kernel_write(void *dst, const void *src, size_t size)
>>   EXPORT_SYMBOL_GPL(probe_kernel_write);
>>
>>   /**
>> + * probe_user_read(): safely attempt to read from a user location
>> + * @dst: pointer to the buffer that shall take the data
>> + * @src: address to read from
>> + * @size: size of the data chunk
>> + *
>> + * Safely read from address @src to the buffer at @dst.  If a kernel fault
>> + * happens, handle that and return -EFAULT.
>> + *
>> + * We ensure that the copy_from_user is executed in atomic context so that
>> + * do_page_fault() doesn't attempt to take mmap_sem.  This makes
>> + * probe_user_read() suitable for use within regions where the caller
>> + * already holds mmap_sem, or other locks which nest inside mmap_sem.
>> + */
>> +
>> +long __weak probe_user_read(void *dst, const void *src, size_t size)
>> +       __attribute__((alias("__probe_user_read")));
> 
> Let's use #defines to deal with per-arch aliases so we can keep the
> inline I'm suggesting below...
> 
>> +
>> +long __probe_user_read(void *dst, const void __user *src, size_t size)
> 
> Please make this __always_inline so the "size" variable can be
> examined for const-ness by the check_object_size() in
> __copy_from_user_inatomic().

Ok, I did as suggested in the patch I just sent.

Would it be worth doing the same with the existing probe_kernel_read() 
and probe_kernel_write() ?

Christophe

> 
> -Kees
> 

      reply	other threads:[~2018-12-03 17:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-19 15:14 Christophe Leroy
2018-10-19 15:42 ` Kees Cook
2018-12-03 17:11   ` Christophe LEROY [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=a6d785e7-c01d-eb3c-89da-e960abc40c6d@c-s.fr \
    --to=christophe.leroy@c-s.fr \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /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