From: Tycho Andersen <tycho@tycho.ws>
To: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
linux-sparse@vger.kernel.org,
kernel-hardening@lists.openwall.com,
linux-kernel@vger.kernel.org
Subject: Re: [RFC v1] copy_{to,from}_user(): only inline when !__CHECKER__
Date: Sun, 9 Dec 2018 14:53:09 -0700 [thread overview]
Message-ID: <20181209215309.GF30796@cisco> (raw)
In-Reply-To: <20181209213951.kumz33u6prb2seqz@ltop.local>
On Sun, Dec 09, 2018 at 10:39:52PM +0100, Luc Van Oostenryck wrote:
> On Sun, Dec 09, 2018 at 02:25:23PM -0700, Tycho Andersen wrote:
> > Hi Al,
> >
> > On Sun, Dec 09, 2018 at 09:02:21PM +0000, Al Viro wrote:
> > > On Sun, Dec 09, 2018 at 01:44:49PM -0700, Tycho Andersen wrote:
> > > > While working on some additional copy_to_user() checks for sparse, I
> > > > noticed that sparse's current copy_to_user() checks are not triggered. This
> > > > is because copy_to_user() is declared as __always_inline, and sparse
> > > > specifically looks for a call instruction to copy_to_user() when it tries
> > > > to apply the checks.
> > > >
> > > > A quick fix is to explicitly not inline when __CHECKER__ is defined, so
> > > > that sparse will be able to analyze all the copy_{to,from}_user calls.
> > > > There may be some refactoring in sparse that we can do to fix this,
> > > > although it's not immediately obvious to me how, hence the RFC-ness of this
> > > > patch.
> > >
> > > Which sparse checks do not trigger? Explain, please - as it is, I had been
> > > unable to guess what could "specifically looks for a call instruction" refer
> > > to.
> >
> > In sparse.c there's check_call_instruction(), which is triggered when
> > there's an instruction of OP_CALL type in the basic block. This simply
> > compares against the name of the call target to determine whether or
> > not to call check_ctu().
> >
> > I think what's happening here is that the call is getting inlined, and
> > so the OP_CALL goes away, and check_call_instruction() never gets
> > called.
>
> Yes, it's what's happening.
>
> There are several more or less bad/good solutions, like:
> * add raw_copy_{to,from}_user() in the list of checked function
> (not inlined in most archs).
But they are inlined on x86 :\
> * add a new annotation to force sparse to check the byte count
> (I'm thinking about __range__/OP_RANGE or something similar).
Yes, I was playing around with inventing some check like this without
the need for an annotation. It's not clear to me if it's going to work
or not yet, though :). Top two patches here are what I was playing
with:
https://github.com/tych0/sparse/commits/check-as-infoleaks
> * do these checks before functions are inlined (but then some
> constant count could not yet be seen as constant).
Yeah, I guess I was wondering if there was some more clever location
in sparse itself we could move these to.
Tycho
next prev parent reply other threads:[~2018-12-09 21:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-09 20:44 [RFC v1] copy_{to,from}_user(): only inline when !__CHECKER__ Tycho Andersen
2018-12-09 21:02 ` Al Viro
2018-12-09 21:25 ` Tycho Andersen
2018-12-09 21:39 ` Luc Van Oostenryck
2018-12-09 21:53 ` Tycho Andersen [this message]
2018-12-09 21:56 ` Al Viro
2018-12-09 22:08 ` Luc Van Oostenryck
2018-12-09 21:46 ` Al Viro
2018-12-09 21:56 ` Tycho Andersen
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=20181209215309.GF30796@cisco \
--to=tycho@tycho.ws \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=luc.vanoostenryck@gmail.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.