linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: "Levin, Alexander" <alexander.levin@verizon.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
	"scientist@fb.com" <scientist@fb.com>,
	"glider@google.com" <glider@google.com>,
	"andreyknvl@google.com" <andreyknvl@google.com>,
	"rostedt@goodmis.org" <rostedt@goodmis.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"mathieu.desnoyers@efficios.com" <mathieu.desnoyers@efficios.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC 1/3] abi_spec: basic definitions of constraints, args and syscalls
Date: Mon, 21 Nov 2016 15:48:17 +0100	[thread overview]
Message-ID: <CACT4Y+af2NC_b7rb_Zy3FTiB9iu9pa7rcdfCKXo7WkkGzbbfag@mail.gmail.com> (raw)
In-Reply-To: <1479317803-17220-2-git-send-email-alexander.levin@verizon.com>

On Wed, Nov 16, 2016 at 6:37 PM,  <alexander.levin@verizon.com> wrote:
> This is a very simple definition of the syscall ABI we can build on. The idea
> is to have a generic description of syscalls, their arguments and return
> values we can use to audit the kernel's implementation vs the specs.
>
> Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
> ---
>  include/uapi/linux/abi_spec.h | 58 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
>  create mode 100644 include/uapi/linux/abi_spec.h
>
> diff --git a/include/uapi/linux/abi_spec.h b/include/uapi/linux/abi_spec.h
> new file mode 100644
> index 0000000..ad1a992
> --- /dev/null
> +++ b/include/uapi/linux/abi_spec.h
> @@ -0,0 +1,58 @@
> +#ifndef ABI_SPEC_H_
> +#define ABI_SPEC_H_
> +
> +#include <linux/fcntl.h>
> +#include <linux/stat.h>
> +#define MAX_CONSTRAINTS 10
> +#define MAX_ARGS 10
> +
> +#define        TYPE_FD         1
> +#define TYPE_INT       2
> +#define TYPE_PTR       3
> +#define TYPE_STRING    4
> +/* ... */
> +
> +#define CONSTRAINT_NON_NULL    (1<<0)
> +#define CONSTRAINT_RANGE       (1<<1)
> +#define CONSTRAINT_ADDRESS_TYPE        (1<<2)
> +#define CONSTRAINT_FD_TYPE     (1<<3)
> +#define CONSTRAINT_ERRNO       (1<<4)
> +#define CONSTRAINT_BITMASK     (1<<5)
> +#define CONSTRAINT_PATH                (1<<6)
> +/* ... */
> +/* A generic constraint on an argument or a return value */
> +struct constraint {
> +       unsigned int flags;             /* bitmask of applied constraints */
> +       union {
> +               struct {                /* int range */
> +                       int int_min;
> +                       int int_max;
> +               };
> +               unsigned long bitmask;  /* allowed flags bitmask */
> +               unsigned long address_flags;    /* Type of allowed addr */
> +               unsigned long fd_flags; /* Type of allowed fd */
> +       };
> +};
> +
> +/* A generic argument (or return value) */
> +struct argument {
> +       const char *name;
> +       int type;                       /* should be a nicer way to do this */
> +
> +       unsigned int nconstraints;      /* can there be more than 1-2? */
> +       struct constraint constraints[MAX_CONSTRAINTS];
> +};


Several observations based on my experience with syzkaller descriptions:
 - there are 2 levels: physical and logical;
   on physical level there are int, pointer, array, struct, union;
   and that's pretty much it.
   on logical level there are flags, bitmasks, file paths, sctp socket fds,
   unix socket names, etc.
   These levels are almost completely orthogonal. It would be useful to
   clearly separate them on description level. E.g. now you have TYPE_PTR and
   TYPE_INT which is physical level; and then TYPE_FD which is also an int.

 - logical types won't fit into 64 bits, there are more of them

 - we need support for recursive types (yes, there are linked lists in
kernel APIs)

 - we need support for input/output data
   currently syzkaller does this only on pointer level, i.e. you
attach direction to pointer target
   but that's not enough, frequently there is a struct where one field
is input and another is output

 - we may need support for reusing types in several arguments
   e.g. you may have a pretty complex type, and you don't want to
write it out a dozen of times

 - we need some support for discriminated syscalls
   if we want to support strace usecase, the support needs to be more
extensive than what syzkaller has;
   i.e. syzkaller can't restore discrimination having actual argument
values (it can do it only in the other direction)

 - I would not create a special support for arguments;
   rather I would create support for structs and struct fields,
   and then pretend that a syscalls effectively accepts a struct by value


How would you like us to collaborate on this?
If you share your git repo, I could form it into something that would
be suitable for syzkaller and incorporate most of the above.


> +/* A generic syscall */
> +struct syscall_spec {
> +       const char *name;
> +       struct argument retval;
> +
> +       unsigned int nargs;
> +       struct argument args[MAX_ARGS];
> +};
> +
> +void abispec_check_pre(const struct syscall_spec *s, ...);
> +void abispec_check_post(const struct syscall_spec *s, long retval, ...);
> +
> +#endif
> --
> 2.7.4

  reply	other threads:[~2016-11-21 14:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-16 17:37 [RFC 0/3] ABI spec - verification alexander.levin
2016-11-16 17:37 ` [RFC 1/3] abi_spec: basic definitions of constraints, args and syscalls alexander.levin
2016-11-21 14:48   ` Dmitry Vyukov [this message]
2016-11-23 14:59     ` alexander.levin
2016-12-12 10:29       ` Dmitry Vyukov
2016-12-12 10:45         ` Dmitry Vyukov
2016-12-14 19:46           ` Dmitry Vyukov
2016-12-14 19:48             ` Dmitry Vyukov
2017-01-04  4:52             ` alexander.levin
2016-12-27 17:23         ` alexander.levin
2016-12-28  7:32           ` Dmitry Vyukov
2016-11-21 15:41   ` Steven Rostedt
2016-11-23 15:03     ` alexander.levin
2016-11-23 15:31       ` Steven Rostedt
2016-11-23 15:33       ` Steven Rostedt
2016-11-16 17:37 ` [RFC 2/3] abi_spec: hooks into syscall to allow pre and post checking alexander.levin
2016-11-21 15:54   ` Steven Rostedt
2016-11-21 15:57     ` Dmitry Vyukov
2016-11-23 15:04       ` alexander.levin
2016-11-16 17:37 ` [RFC 3/3] abi_spec: example spec for open(), placeholder for rest of syscalls alexander.levin
2016-11-16 17:46 ` [RFC 0/3] ABI spec - verification Thomas Gleixner
2016-11-21 14:25 ` Dmitry Vyukov
2016-11-23 14:36   ` alexander.levin
2016-12-12 10:12     ` Dmitry Vyukov

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=CACT4Y+af2NC_b7rb_Zy3FTiB9iu9pa7rcdfCKXo7WkkGzbbfag@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=alexander.levin@verizon.com \
    --cc=andreyknvl@google.com \
    --cc=arnd@arndb.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=glider@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=rostedt@goodmis.org \
    --cc=scientist@fb.com \
    --cc=tglx@linutronix.de \
    /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).