From: Vaishali Thakkar <vaishali.thakkar@oracle.com>
To: Kees Cook <keescook@chromium.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Al Viro <viro@zeniv.linux.org.uk>,
David Windsor <dwindsor@gmail.com>
Subject: Re: [kernel-hardening] [RFC PATCH] lib: Harden csum_partial_copy_from_user
Date: Thu, 3 Nov 2016 07:44:35 +0530 [thread overview]
Message-ID: <581A9D8B.5040200@oracle.com> (raw)
In-Reply-To: <CAGXu5j+go+Fr2OeF-R4BtVHRcBRrC0TaU477J4RwEAe4zDRZ9A@mail.gmail.com>
On Thursday 03 November 2016 03:29 AM, Kees Cook wrote:
> On Wed, Nov 2, 2016 at 2:44 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi,
>>
>> On Wed, Nov 02, 2016 at 10:32:49PM +0530, Vaishali Thakkar wrote:
>>> The routine csum_partial_copy_from_user is same as csum_partial_copy
>>> but it copies from user space for the checksumming. In other respects
>>> it is identical, and can be used to copy an arbitrarily large buffer
>>> from userspace into the kernel. Conceptually this exposes a similar
>>> attack surface like copy_from_user. So, to validate the given address
>>> we should call check_object_size here.
>>
>> Thanks for looking at this! I agree that we should be trying lock down these
>> homebrew/specialised copy_{to,from}_user routines.
>
> Yes, I'm glad to have more eyes on this. I did notice that these are
> almost exclusively used in networking. I'd be curious to see how
> noticeable this is on performance (though see my inlining comment
> below...)
>
>>
>> However...
>>
>>> @@ -158,6 +159,7 @@ csum_partial_copy_from_user(const void __user *src, void *dst, int len,
>>> {
>>> int missing;
>>>
>>> + check_object_size(dst, len, false);
>>> missing = __copy_from_user(dst, src, len);
>>
>> ... here we're just calling into the architecture-specific __copy_from_user(),
>> and I know that both arm64 and x86 have a check_object_size() call in their
>> __copy_from_user() implementations.
>
> Another issue here is that csum_partial_copy_from_user() isn't an
> inline function, so we lose the performance benefits of ignoring
> builtin_cost uses.
>
>> Is that missing on some architectures?
>
> Every architecture is _slightly_ different. Most put the check in
> __copy_from_user() so it's correctly caught. (x86 puts them in both
> since copy*() calls _copy*(), not __copy*() ... >_<)
I think still there are some architectures which didn't put the check
in __copy_from_user() [eg. tile].
>> I think we need to figure out where check_object_size() and other checks (e.g.
>> kasan_check_size) are expected to live in the hierarchy of uaccess copy
>> primitives (and/or if they should also live in {get,put)_user()).
>
> Yes, totally agreed. This is going to be needed for the next step of
> usercopy hardening, too. We need to have an arch-specific
> __actually_do_the_copy() function that has none of the instrumentation
> and is only visible to the usercopy functions. Then we can separate
> check logic from the action itself. (Right now we can't pass any
> additional information to the check (e.g. whether to make exceptions
> to slab whitelisting, etc) because the check is deep in __copy*user().
I was actually wondering if there are any cases where we need any
architecture specific extra check(s)?
>> I had a plan to try to refactor the generic uaccess code so that we could put
>> those checks in one place, but I put that on hold as Al Viro was doing some
>> overlapping refactoring of all the uaccess primitives (and I got busy with some
>> other work).
>
> Al, is your pass at improving uaccess currently finished, or do you
> have more changes coming?
>
> -Kees
>
--
Vaishali
next prev parent reply other threads:[~2016-11-03 2:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 17:02 [kernel-hardening] [RFC PATCH] lib: Harden csum_partial_copy_from_user Vaishali Thakkar
2016-11-02 20:44 ` Mark Rutland
2016-11-02 21:59 ` Kees Cook
2016-11-03 2:14 ` Vaishali Thakkar [this message]
2016-11-03 4:23 ` Mark Rutland
2016-11-03 4:56 ` Vaishali Thakkar
2016-11-03 18:05 ` Mark Rutland
2016-11-04 10:03 ` Vaishali Thakkar
2016-11-03 5:03 ` Al Viro
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=581A9D8B.5040200@oracle.com \
--to=vaishali.thakkar@oracle.com \
--cc=dwindsor@gmail.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=mark.rutland@arm.com \
--cc=viro@zeniv.linux.org.uk \
/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.