From: David Malcolm <dmalcolm@redhat.com>
To: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>
Cc: gcc-patches@gcc.gnu.org, linux-toolchains@vger.kernel.org
Subject: Re: [PATCH 2/6] Add returns_zero_on_success/failure attributes
Date: Thu, 18 Nov 2021 18:15:46 -0500 [thread overview]
Message-ID: <08395df65e442581f2a44a786a489cf1d4c2e34c.camel@redhat.com> (raw)
In-Reply-To: <CAAgBjMnbjYMy95=qXF4_qmNN4gy5BUYEFLxMBqNCOCdQE0MyeQ@mail.gmail.com>
On Wed, 2021-11-17 at 14:53 +0530, Prathamesh Kulkarni wrote:
> On Tue, 16 Nov 2021 at 03:42, David Malcolm <dmalcolm@redhat.com>
> wrote:
> >
> > On Mon, 2021-11-15 at 12:33 +0530, Prathamesh Kulkarni wrote:
> > > On Sun, 14 Nov 2021 at 02:07, David Malcolm via Gcc-patches
> > > <gcc-patches@gcc.gnu.org> wrote:
> > > >
> > > > This patch adds two new attributes. The followup patch makes
> > > > use of
> > > > the attributes in -fanalyzer.
> >
> > [...snip...]
> >
> > > > +/* Handle "returns_zero_on_failure" and
> > > > "returns_zero_on_success"
> > > > attributes;
> > > > + arguments as in struct attribute_spec.handler. */
> > > > +
> > > > +static tree
> > > > +handle_returns_zero_on_attributes (tree *node, tree name,
> > > > tree,
> > > > int,
> > > > + bool *no_add_attrs)
> > > > +{
> > > > + if (!INTEGRAL_TYPE_P (TREE_TYPE (*node)))
> > > > + {
> > > > + error ("%qE attribute on a function not returning an
> > > > integral type",
> > > > + name);
> > > > + *no_add_attrs = true;
> > > > + }
> > > > + return NULL_TREE;
> > > Hi David,
> >
> > Thanks for the ideas.
> >
> > > Just curious if a warning should be emitted if the function is
> > > marked
> > > with the attribute but it's return value isn't actually 0 ?
> >
> > That sounds like a worthwhile extension of the idea. It should be
> > possible to identify functions that can't return zero or non-zero
> > that
> > have been marked as being able to.
> >
> > That said:
> >
> > (a) if you apply the attribute to a function pointer for a
> > callback,
> > you could have an implementation of the callback that always fails
> > and
> > returns, say, -1; should the warning complain that the function has
> > the
> > "returns_zero_on_success" property and is always returning -1?
> Ah OK. In that case, emitting a diagnostic if the return value
> isn't 0, doesn't make sense for "returns_zero_on_success" since the
> function "always fails".
> Thanks for pointing out!
> >
> > (b) the attributes introduce a concept of "success" vs "failure",
> > which
> > might be hard for a machine to determine. It's only used later on
> > in
> > terms of the events presented to the user, so that -fanalyzer can
> > emit
> > e.g. "when 'copy_from_user' fails", which IMHO is easier to read
> > than
> > "when 'copy_from_user' returns non-zero".
> Indeed.
> >
> > >
> > > There are other constants like -1 or 1 that are often used to
> > > indicate
> > > error, so maybe tweak the attribute to
> > > take the integer as an argument ?
> > > Sth like returns_int_on_success(cst) /
> > > returns_int_on_failure(cst) ?
> >
> > Those could work nicely; I like the idea of them being
> > supplementary to
> > the returns_zero_on_* ones.
> >
> > I got the urge to bikeshed about wording; some ideas:
> > success_return_value(CST)
> > failure_return_value(CST)
> > or maybe additionally:
> > success_return_range(LOWER_BOUND_CST, UPPER_BOUND_CST)
> > failure_return_range(LOWER_BOUND_CST, UPPER_BOUND_CST)
> Extending to range is a nice idea ;-)
> Apart from success / failure, if we just had an attribute
> return_range(low_cst, high_cst), I suppose that could
> be useful for return value optimization ?
Perhaps. All of this sounds like scope creep beyond my immediate
requirements though :)
> >
> > I can also imagine a
> > sets_errno_on_failure
> > attribute being useful (and perhaps a "doesnt_touch_errno"???)
> More generally, would it be a good idea to provide attributes for
> mod/ref anaylsis ?
> So sth like:
> void foo(void) __attribute__((modifies(errno)));
> which would state that foo modifies errno, but neither reads nor
> modifies any other global var.
> and
> void bar(void) __attribute__((reads(errno)))
> which would state that bar only reads errno, and doesn't modify or
> read any other global var.
> I guess that can benefit optimization, since we can have better
> context about side-effects of a function call.
> For success / failure context, we could add attributes
> modifies_on_success, modifies_on_failure ?
Likewise - sounds potentially useful, but I don't need this for this
kernel trust boundaries patch kit.
Dave
>
> Thanks,
> Prathamesh
> >
> > > Also, would it make sense to extend it for pointers too for
> > > returning
> > > NULL on success / failure ?
> >
> > Possibly expressible by generalizing it to allow pointer types, or
> > by
> > adding this pair:
> >
> > returns_null_on_failure
> > returns_null_on_success
> >
> > or by using the "range" idea above.
> >
> > In terms of scope, for the trust boundary stuff, I want to be able
> > to
> > express the idea that a call can succeed vs fail, what the success
> > vs
> > failure is in terms of nonzero vs zero, and to be able to wire up
> > the
> > heuristic that if it looks like a "copy function" (use of access
> > attributes and a size), that success/failure can mean "copies all
> > of
> > it" vs "copies none of it" (which seems to get decent test coverage
> > on
> > the Linux kernel with the copy_from/to_user fns).
> >
> > Thanks
> > Dave
> >
> >
> > >
> > > Thanks,
> > > Prathamesh
> >
> > [...snip...]
> >
>
next prev parent reply other threads:[~2021-11-18 23:15 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-13 20:37 [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries David Malcolm
2021-11-13 20:37 ` [PATCH 1a/6] RFC: Implement "#pragma GCC custom_address_space" David Malcolm
2021-11-13 20:37 ` [PATCH 1b/6] Add __attribute__((untrusted)) David Malcolm
2021-12-09 22:54 ` Martin Sebor
2022-01-06 15:10 ` David Malcolm
2022-01-06 18:59 ` Martin Sebor
2021-11-13 20:37 ` [PATCH 2/6] Add returns_zero_on_success/failure attributes David Malcolm
2021-11-15 7:03 ` Prathamesh Kulkarni
2021-11-15 14:45 ` Peter Zijlstra
2021-11-15 22:30 ` David Malcolm
2021-11-15 22:12 ` David Malcolm
2021-11-17 9:23 ` Prathamesh Kulkarni
2021-11-17 22:43 ` Joseph Myers
2021-11-18 20:08 ` Segher Boessenkool
2021-11-18 23:45 ` David Malcolm
2021-11-19 21:52 ` Segher Boessenkool
2021-11-18 23:34 ` David Malcolm
2021-12-06 18:34 ` Martin Sebor
2021-11-18 23:15 ` David Malcolm [this message]
2021-11-13 20:37 ` [PATCH 3/6] analyzer: implement infoleak detection David Malcolm
2021-11-13 20:37 ` [PATCH 4a/6] analyzer: implement region::untrusted_p in terms of custom address spaces David Malcolm
2021-11-13 20:37 ` [PATCH 4b/6] analyzer: implement region::untrusted_p in terms of __attribute__((untrusted)) David Malcolm
2021-11-13 20:37 ` [PATCH 5/6] analyzer: use region::untrusted_p in taint detection David Malcolm
2021-11-13 20:37 ` [PATCH 6/6] Add __attribute__ ((tainted)) David Malcolm
2022-01-06 14:08 ` PING (C/C++): " David Malcolm
2022-01-10 21:36 ` PING^2 " David Malcolm
2022-01-12 4:36 ` Jason Merrill
2022-01-12 15:33 ` David Malcolm
2022-01-13 19:08 ` Jason Merrill
2022-01-14 1:25 ` [committed] Add __attribute__ ((tainted_args)) David Malcolm
2021-11-13 23:20 ` [PATCH 0/6] RFC: adding support to GCC for detecting trust boundaries Peter Zijlstra
2021-11-14 2:54 ` David Malcolm
2021-11-14 13:54 ` Miguel Ojeda
2021-12-06 18:12 ` Martin Sebor
2021-12-06 19:40 ` Segher Boessenkool
2021-12-09 0:06 ` David Malcolm
2021-12-09 0:41 ` Segher Boessenkool
2021-12-09 16:42 ` Martin Sebor
2021-12-09 23:40 ` Segher Boessenkool
2021-12-08 23:11 ` David Malcolm
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=08395df65e442581f2a44a786a489cf1d4c2e34c.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=prathamesh.kulkarni@linaro.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).