linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Mark Rutland <mark.rutland@arm.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-doc@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Kostya Serebryany <kcc@google.com>,
	linux-kselftest@vger.kernel.org,
	Chintan Pandya <cpandya@codeaurora.org>,
	Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	linux-arch@vger.kernel.org, Jacob Bramley <Jacob.Bramley@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Evgeniy Stepanov <eugenis@google.com>,
	Kees Cook <keescook@chromium.org>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Lee Smith <Lee.Smith@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v6 11/11] arm64: annotate user pointers casts detected by sparse
Date: Thu, 6 Sep 2018 22:10:04 +0200	[thread overview]
Message-ID: <20180906201003.54bqs7sacynt5uyq@ltop.local> (raw)
In-Reply-To: <5074b9b6-2b8d-c410-f908-b4c17dacbb2c@arm.com>

On Thu, Sep 06, 2018 at 03:13:16PM +0100, Vincenzo Frascino wrote:
> On 05/09/18 20:03, Luc Van Oostenryck wrote:
> > I think that at this point, it would be nice to have a clear description
> > of the problem and what sort of checks are wanted.
> >
> 
> 
> The problem we are trying to address here is to identify when the user pointers
> are cast to integer types and to sanitize (when required) the kernel, when this
> happens.
> 
> The way on which we are trying to address this problem based on what Andrey
> proposed in his patch-set is to use the Top Byte Ignore feature (which is a 64 bit
> specific feature).
> 
> Based on what I said I think that we require 2 'modifiers':
> - __compat (or __compat_ptr) used when the kernel is dealing with user compat 
> pointers (32 bit, they can not be tagged). It should behave like force
> (silence warnings), but having something separate IMO makes more clear the
> intention of what we are trying to do.
> - __tagged (or __tagged_ptr) used when the kernel is dealing with user normal
> pointers (which can be tagged). In this case sparse should still be able to trigger
> a warning (that can be disabled by default as I was proposing in my previous email).
> When we put a tagged identifier we declare that we analyzed the code impacted by
> the conversion and eventually sanitized it. Having the warning still there allows us
> or whoever is looking at the code to always go back to the identified issue.  

OK. Thanks for the explanation.

So, the way I see things from a type checking perspective, is that
'being (potentially) tagged' is a new property of values, othogonal
the the concept of address space. Leaving the other address spaces
(__iomem, __percpu & __rcu) aside, it should be possible to have
__user & __kernel tagged pointers as well as tagged ulongs:
	__user __tagged *
	__kernel __tagged *
	ulong __tagged
in addition of the usuals:
	__user *
	__kernel *
	ulong
But some of them are banished or meaningless:
	__user *            (all __user pointers are potentially tagged)
	__kernel __tagged * (tags are only for user space)
	ulong __tagged      (pointers need to be untagged during conversion)
So, only the followings remain:
	__user __tagged *
	__kernel *
	ulong
and the property '__tagged' becomes equivalent to '__user'.
Thus '__tagged' can be implicit and this would have the advantage
of not needing to change any annotations.

Since the conversion '__user *' to '__kernel *' is already covered
by the default sparse warnings, only the conversion '__user' to
'ulong' need to be covered (and this is already covered by the new
option -Wcast-from-as) but that is only fine for detection. After
detection and auditing, several solution are possible:
1) simply add '__force' in the cast (this is very bad)
2) moving this '__force' inside a macro '__untag_ptr(x)' would already
   more acceptable but is fundamentaly the same as 1)
3) a weaker form of '__force', '__force_as', will do the trick nicely
   as long as __user is equated to __tagged (and could be useful on
   its own but could also hide real AS conversion problems).
4) a more specific solution would be to effectively add a new attribute,
   '__tagged', to define '__user' like:
	#define __user attribute((noderef,address_space(1),tagged))
   and have something like '__untag', a weaker form of __force meaning:
   "I know what I'm doing regarding conversion from 'tagged'". 

Neither 3) nor 4) should be much work but while I firmly think that
4) is the most correct solution, I'm not sure it's worth the added
complexity, certainly if KHWASAN is not meant to be upstreamed.

For the compat pointers, I'm less sure to understand the situation:
even if they can't be tagged, treating them as the other __user
pointers will still be OK (but I understand that it could be
interesting to be able to track them, it's just that it's independent
from the __tagged property).


-- Luc

  reply	other threads:[~2018-09-06 20:10 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 11:41 [PATCH v6 00/11] arm64: untag user pointers passed to the kernel Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 01/11] arm64: add type casts to untagged_addr macro Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 02/11] uaccess: add untagged_addr definition for other arches Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 03/11] arm64: untag user addresses in access_ok and __uaccess_mask_ptr Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 04/11] mm, arm64: untag user addresses in mm/gup.c Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 05/11] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 06/11] arm64: untag user address in __do_user_fault Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 07/11] fs, arm64: untag user address in copy_mount_options Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 08/11] usb, arm64: untag user addresses in devio Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 09/11] arm64: update Documentation/arm64/tagged-pointers.txt Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 10/11] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov
2018-08-30 11:41 ` [PATCH v6 11/11] arm64: annotate user pointers casts detected by sparse Andrey Konovalov
2018-08-31  8:11   ` Luc Van Oostenryck
2018-08-31 13:42     ` Al Viro
2018-09-03 12:34       ` Andrey Konovalov
2018-09-03 13:49         ` Vincenzo Frascino
2018-09-03 15:10           ` Luc Van Oostenryck
2018-09-04 11:27             ` Vincenzo Frascino
2018-09-05 19:03               ` Luc Van Oostenryck
2018-09-06 14:13                 ` Vincenzo Frascino
2018-09-06 20:10                   ` Luc Van Oostenryck [this message]
2018-09-03 13:56         ` Al Viro
2018-09-06 21:13   ` Linus Torvalds
2018-09-06 21:16     ` Linus Torvalds
2018-09-06 23:08       ` Luc Van Oostenryck
2018-09-07 15:26       ` Catalin Marinas
2018-09-07 16:30         ` Linus Torvalds
2018-09-11 16:41           ` Catalin Marinas
2018-09-17 17:01             ` Andrey Konovalov
2018-09-24 15:04               ` Andrey Konovalov
2018-09-28 17:50               ` Catalin Marinas
2018-10-02 13:19                 ` Andrey Konovalov
2018-09-14  1:25   ` [LKP] [arm64] 7b5b51e7b3: kvm-unit-tests.rmap_chain.fail kernel test robot
2018-08-30 11:48 ` [PATCH v6 00/11] arm64: untag user pointers passed to the kernel Andrey Konovalov

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=20180906201003.54bqs7sacynt5uyq@ltop.local \
    --to=luc.vanoostenryck@gmail.com \
    --cc=Jacob.Bramley@arm.com \
    --cc=Lee.Smith@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Ruben.Ayrapetyan@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=cpandya@codeaurora.org \
    --cc=dvyukov@google.com \
    --cc=eugenis@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kcc@google.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=shuah@kernel.org \
    --cc=vincenzo.frascino@arm.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /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).