BPF_FUNC_* constants for sys/linux

[Lorenz Bauer]

Hi,

The file include/uapi/linux/bpf.h has some preprocessor magic to define available

functions. After a quick look it seems like this isn't supporter by syz-extract, and

the constants are missing from the generated files.

Is it possible to add support for that macro?

Best

Lorenz

[Dmitry Vyukov]

Hi Lorenz,

What exactly macro do you mean?
Generally any macro should work, or just anything b/c what syz-extract
does is it creates a program like:

uint64 values[] = {..., FOO, ...};

So whatever FOO is, if C compiler can chew it, it should work.

There are some macros with arguments, e.g. FOO(X). What we do for
these so far is:

// in descriptions file
define FOO_X FOO(X)

and then you can use FOO_X in descriptions.

[Lorenz Bauer]

On Thu, 11 Jun 2020 at 15:39, Dmitry Vyukov <dvy...@google.com> wrote:
>
> On Thu, Jun 11, 2020 at 4:26 PM 'Lorenz Bauer' via syzkaller
> <syzk...@googlegroups.com> wrote:
> >
> > Hi,
> >
> > The file include/uapi/linux/bpf.h has some preprocessor magic to define available
> > functions. After a quick look it seems like this isn't supporter by syz-extract, and
> > the constants are missing from the generated files.
> >
> > Is it possible to add support for that macro?
>
> Hi Lorenz,
>
> What exactly macro do you mean?

Sorry, I should have just pasted an example:

#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
FN(map_lookup_elem), \
...

#define __BPF_ENUM_FN(x) BPF_FUNC_ ## x
enum bpf_func_id {
__BPF_FUNC_MAPPER(__BPF_ENUM_FN)
__BPF_FUNC_MAX_ID,
};
#undef __BPF_ENUM_FN

This results in enum values like BPF_FUNC_unspec, BPF_FUNC_map_lookup_elem, etc.
Interestingly, __BPF_FUNC_MAX_ID is generated correctly.

> Generally any macro should work, or just anything b/c what syz-extract
> does is it creates a program like:
>
> uint64 values[] = {..., FOO, ...};
>
> So whatever FOO is, if C compiler can chew it, it should work.
>
> There are some macros with arguments, e.g. FOO(X). What we do for
> these so far is:
>
> // in descriptions file
> define FOO_X FOO(X)
>
> and then you can use FOO_X in descriptions.

This is to "hardcode" the value of some macro invocations I guess?
I think that doesn't work correctly here because the macro is used to define
an enum.

--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com

[Dmitry Vyukov]

On Thu, Jun 11, 2020 at 4:56 PM Lorenz Bauer <l...@cloudflare.com> wrote:
>
> On Thu, 11 Jun 2020 at 15:39, Dmitry Vyukov <dvy...@google.com> wrote:
> >
> > On Thu, Jun 11, 2020 at 4:26 PM 'Lorenz Bauer' via syzkaller
> > <syzk...@googlegroups.com> wrote:
> > >
> > > Hi,
> > >
> > > The file include/uapi/linux/bpf.h has some preprocessor magic to define available
> > > functions. After a quick look it seems like this isn't supporter by syz-extract, and
> > > the constants are missing from the generated files.
> > >
> > > Is it possible to add support for that macro?
> >
> > Hi Lorenz,
> >
> > What exactly macro do you mean?
>
> Sorry, I should have just pasted an example:
>
> #define __BPF_FUNC_MAPPER(FN) \
> FN(unspec), \
> FN(map_lookup_elem), \
> ...
>
> #define __BPF_ENUM_FN(x) BPF_FUNC_ ## x
> enum bpf_func_id {
> __BPF_FUNC_MAPPER(__BPF_ENUM_FN)
> __BPF_FUNC_MAX_ID,
> };
> #undef __BPF_ENUM_FN
>
> This results in enum values like BPF_FUNC_unspec, BPF_FUNC_map_lookup_elem, etc.
> Interestingly, __BPF_FUNC_MAX_ID is generated correctly.

This works for me. I did:

-bpf_lookup_flags = BPF_F_LOCK
+bpf_lookup_flags = BPF_F_LOCK, BPF_FUNC_map_lookup_elem

Then run make extract and got:

BPF_FUNC_INFO_SIZE = 8
+BPF_FUNC_map_lookup_elem = 1
BPF_F_ALLOW_MULTI = 2

> > Generally any macro should work, or just anything b/c what syz-extract
> > does is it creates a program like:
> >
> > uint64 values[] = {..., FOO, ...};
> >
> > So whatever FOO is, if C compiler can chew it, it should work.
> >
> > There are some macros with arguments, e.g. FOO(X). What we do for
> > these so far is:
> >
> > // in descriptions file
> > define FOO_X FOO(X)
> >
> > and then you can use FOO_X in descriptions.
>
> This is to "hardcode" the value of some macro invocations I guess?
> I think that doesn't work correctly here because the macro is used to define
> an enum.

Now seeing what you are trying to do, I think this is not necessary here.

But this can be used for following. Consider kernel contains:

#define FOO(X) (((X) << 2) + 42)

In the syzkaller descriptions we want to use:

const[FOO(BAR)]

This will not work, such syntax is not supported.

What we can do is:

const[FOO_BAR]
define FOO_BAR FO(BAR)

This will work.

[Lorenz Bauer]

Ah, I didn't understand that the build process only extracts the
"needed" constants,
not all of the available ones.

>
> > > Generally any macro should work, or just anything b/c what syz-extract
> > > does is it creates a program like:
> > >
> > > uint64 values[] = {..., FOO, ...};
> > >
> > > So whatever FOO is, if C compiler can chew it, it should work.
> > >
> > > There are some macros with arguments, e.g. FOO(X). What we do for
> > > these so far is:
> > >
> > > // in descriptions file
> > > define FOO_X FOO(X)
> > >
> > > and then you can use FOO_X in descriptions.
> >
> > This is to "hardcode" the value of some macro invocations I guess?
> > I think that doesn't work correctly here because the macro is used to define
> > an enum.
>
> Now seeing what you are trying to do, I think this is not necessary here.
>
> But this can be used for following. Consider kernel contains:
>
> #define FOO(X) (((X) << 2) + 42)
>
> In the syzkaller descriptions we want to use:
>
> const[FOO(BAR)]
>
> This will not work, such syntax is not supported.
>
> What we can do is:
>
> const[FOO_BAR]
> define FOO_BAR FO(BAR)
>
> This will work.

Makes sense now, thank you for explaining!