linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* ARM seccomp filters and EABI/OABI
@ 2013-10-23 21:02 Andy Lutomirski
  2013-10-24 19:11 ` [libseccomp-discuss] " Paul Moore
  2013-10-24 19:55 ` Richard Weinberger
  0 siblings, 2 replies; 14+ messages in thread
From: Andy Lutomirski @ 2013-10-23 21:02 UTC (permalink / raw)
  To: libseccomp-discuss, Will Drewry, Kees Cook, linux-kernel

I'm looking at the seccomp code, the ARM entry code, and the
syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
speak ARM assembly doesn't help.)  My basic question is: what happens
if an OABI syscall happens?

AFAICS, the syscall arguments for EABI are r0..r5, although their
ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
lost as to what it is.  The seccomp_bpf_load function won't load r6,
so there had better not be anything useful in there...  (Also, struct
seccomp_data will have issues with a seventh "argument".)

But what happens to the syscall number?  For an EABI syscall, it's in
r7.  For an OABI syscall, it's in the swi instruction and gets copied
to r7 on entry.  If a debugger changes r7, presumably the syscall
number changes.

Oddly, there are two different syscall tables.  The major differences
seem to be that some of the OABI entries have their argument order
changed.  But there's also a magic constant 0x900000 added to the
syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
it reflected in ucontext's r7?

I'm a bit surprised to see that both the EABI and OABI ABIs show up as
AUDIT_ARCH_ARM.

Can any of you shed some light on this?  I don't have an ARM system I
can test on, but if one of you can point me at a decent QEMU image, I
can play around.

For reference, I'm working on userspace code to decode a TRAP and
eventually to allow syscall emulation (either by emulating the syscall
inside the signal handler and setting the return value or (egads!) by
changing the syscall and restarting it -- the latter is probably
impossible if the original syscall came in through OABI and may be
generally impossible if userspace expects any of the argument
registers to be preserved).


* I think that a syscall with signature long func(int a, long long b,
int c, int d, int e) ends up with c in r1 and b in r2/r3.  The
syscall(2) manpage appears to be entirely wrong.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-23 21:02 ARM seccomp filters and EABI/OABI Andy Lutomirski
@ 2013-10-24 19:11 ` Paul Moore
  2013-10-24 21:14   ` Andy Lutomirski
  2013-10-30 17:19   ` Kees Cook
  2013-10-24 19:55 ` Richard Weinberger
  1 sibling, 2 replies; 14+ messages in thread
From: Paul Moore @ 2013-10-24 19:11 UTC (permalink / raw)
  To: libseccomp-discuss; +Cc: Andy Lutomirski, Will Drewry, Kees Cook, linux-kernel

On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
> I'm looking at the seccomp code, the ARM entry code, and the
> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> speak ARM assembly doesn't help.)

I suspect Kees, and perhaps Will, will be able to provide the best answers, 
but my thoughts are below.

> My basic question is: what happens if an OABI syscall happens?

Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff is 
EABI I don't think there is much reason to worry about OABI.  I know this 
doesn't answer your question, but perhaps this provides some context.

> AFAICS, the syscall arguments for EABI are r0..r5, although their
> ordering is a bit odd*.

Hmmm, that could complicate things a bit - do you know if they are put in a 
more "standard" order by the time they are accessed in seccomp_bpf_load() via 
task_pt_regs()?  If not, we likely need to come up with some special handling 
in libseccomp to account for this.

> For OABI, r6 seems to play some role, but I'm
> lost as to what it is.  The seccomp_bpf_load function won't load r6,
> so there had better not be anything useful in there...  (Also, struct
> seccomp_data will have issues with a seventh "argument".)
> 
> But what happens to the syscall number?  For an EABI syscall, it's in
> r7.  For an OABI syscall, it's in the swi instruction and gets copied
> to r7 on entry.  If a debugger changes r7, presumably the syscall
> number changes.
> 
> Oddly, there are two different syscall tables.  The major differences
> seem to be that some of the OABI entries have their argument order
> changed.  But there's also a magic constant 0x900000 added to the
> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
> it reflected in ucontext's r7?

Thankfully, I've been able to ignore most of this.

> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> AUDIT_ARCH_ARM.

Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There are 
similar issues with x32; not quite as bad as with ARM, but still ... 

> Can any of you shed some light on this?  I don't have an ARM system I
> can test on, but if one of you can point me at a decent QEMU image, I
> can play around.

I know Kees had one at one point, although I remember him commenting that it 
was painfully slow under QEMU.

> For reference, I'm working on userspace code to decode a TRAP and
> eventually to allow syscall emulation (either by emulating the syscall
> inside the signal handler and setting the return value or (egads!) by
> changing the syscall and restarting it -- the latter is probably
> impossible if the original syscall came in through OABI and may be
> generally impossible if userspace expects any of the argument
> registers to be preserved).
> 
> 
> * I think that a syscall with signature long func(int a, long long b,
> int c, int d, int e) ends up with c in r1 and b in r2/r3.  The
> syscall(2) manpage appears to be entirely wrong.

-- 
paul moore
security and virtualization @ redhat


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ARM seccomp filters and EABI/OABI
  2013-10-23 21:02 ARM seccomp filters and EABI/OABI Andy Lutomirski
  2013-10-24 19:11 ` [libseccomp-discuss] " Paul Moore
@ 2013-10-24 19:55 ` Richard Weinberger
  2013-10-28 21:53   ` Paul Moore
  1 sibling, 1 reply; 14+ messages in thread
From: Richard Weinberger @ 2013-10-24 19:55 UTC (permalink / raw)
  To: Andy Lutomirski; +Cc: libseccomp-discuss, Will Drewry, Kees Cook, linux-kernel

On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> I'm looking at the seccomp code, the ARM entry code, and the
> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> speak ARM assembly doesn't help.)  My basic question is: what happens
> if an OABI syscall happens?
>
> AFAICS, the syscall arguments for EABI are r0..r5, although their
> ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
> lost as to what it is.  The seccomp_bpf_load function won't load r6,
> so there had better not be anything useful in there...  (Also, struct
> seccomp_data will have issues with a seventh "argument".)
>
> But what happens to the syscall number?  For an EABI syscall, it's in
> r7.  For an OABI syscall, it's in the swi instruction and gets copied
> to r7 on entry.  If a debugger changes r7, presumably the syscall
> number changes.
>
> Oddly, there are two different syscall tables.  The major differences
> seem to be that some of the OABI entries have their argument order
> changed.  But there's also a magic constant 0x900000 added to the
> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
> it reflected in ucontext's r7?
>
> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> AUDIT_ARCH_ARM.
>
> Can any of you shed some light on this?  I don't have an ARM system I
> can test on, but if one of you can point me at a decent QEMU image, I
> can play around.

Maybe this helps:
http://people.debian.org/~aurel32/qemu/armel/

> For reference, I'm working on userspace code to decode a TRAP and
> eventually to allow syscall emulation (either by emulating the syscall
> inside the signal handler and setting the return value or (egads!) by
> changing the syscall and restarting it -- the latter is probably
> impossible if the original syscall came in through OABI and may be
> generally impossible if userspace expects any of the argument
> registers to be preserved).
>
>
> * I think that a syscall with signature long func(int a, long long b,
> int c, int d, int e) ends up with c in r1 and b in r2/r3.  The
> syscall(2) manpage appears to be entirely wrong.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Thanks,
//richard

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-24 19:11 ` [libseccomp-discuss] " Paul Moore
@ 2013-10-24 21:14   ` Andy Lutomirski
  2013-10-28 22:02     ` Paul Moore
  2013-10-30 17:19   ` Kees Cook
  1 sibling, 1 reply; 14+ messages in thread
From: Andy Lutomirski @ 2013-10-24 21:14 UTC (permalink / raw)
  To: Paul Moore; +Cc: libseccomp-discuss, Will Drewry, Kees Cook, linux-kernel

On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@redhat.com> wrote:
> On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
>> I'm looking at the seccomp code, the ARM entry code, and the
>> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>> speak ARM assembly doesn't help.)
>
> I suspect Kees, and perhaps Will, will be able to provide the best answers,
> but my thoughts are below.
>
>> My basic question is: what happens if an OABI syscall happens?
>
> Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff is
> EABI I don't think there is much reason to worry about OABI.  I know this
> doesn't answer your question, but perhaps this provides some context.

Are you sure you don't support it?  What actually happens if someone
writes an EABI program that issues an OABI syscall?  (I'm hoping that
the syscall nr ends up offset by 0x900000, but I'm not sure.)

>
>> AFAICS, the syscall arguments for EABI are r0..r5, although their
>> ordering is a bit odd*.
>
> Hmmm, that could complicate things a bit - do you know if they are put in a
> more "standard" order by the time they are accessed in seccomp_bpf_load() via
> task_pt_regs()?  If not, we likely need to come up with some special handling
> in libseccomp to account for this.

I don't think that such a think is possible.  It depends on the
signature of the particular syscall, and I don't know if there's any
table of these things.


>
>> For OABI, r6 seems to play some role, but I'm
>> lost as to what it is.  The seccomp_bpf_load function won't load r6,
>> so there had better not be anything useful in there...  (Also, struct
>> seccomp_data will have issues with a seventh "argument".)
>>
>> But what happens to the syscall number?  For an EABI syscall, it's in
>> r7.  For an OABI syscall, it's in the swi instruction and gets copied
>> to r7 on entry.  If a debugger changes r7, presumably the syscall
>> number changes.
>>
>> Oddly, there are two different syscall tables.  The major differences
>> seem to be that some of the OABI entries have their argument order
>> changed.  But there's also a magic constant 0x900000 added to the
>> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
>> it reflected in ucontext's r7?
>
> Thankfully, I've been able to ignore most of this.
>
>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>> AUDIT_ARCH_ARM.
>
> Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There are
> similar issues with x32; not quite as bad as with ARM, but still ...

As long as the combination of AUDIT_ARCH and nr uniquely identifies a
syscall and its ABI, life should be good.

--Andy

>
>> Can any of you shed some light on this?  I don't have an ARM system I
>> can test on, but if one of you can point me at a decent QEMU image, I
>> can play around.
>
> I know Kees had one at one point, although I remember him commenting that it
> was painfully slow under QEMU.
>
>> For reference, I'm working on userspace code to decode a TRAP and
>> eventually to allow syscall emulation (either by emulating the syscall
>> inside the signal handler and setting the return value or (egads!) by
>> changing the syscall and restarting it -- the latter is probably
>> impossible if the original syscall came in through OABI and may be
>> generally impossible if userspace expects any of the argument
>> registers to be preserved).
>>
>>
>> * I think that a syscall with signature long func(int a, long long b,
>> int c, int d, int e) ends up with c in r1 and b in r2/r3.  The
>> syscall(2) manpage appears to be entirely wrong.
>
> --
> paul moore
> security and virtualization @ redhat
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ARM seccomp filters and EABI/OABI
  2013-10-24 19:55 ` Richard Weinberger
@ 2013-10-28 21:53   ` Paul Moore
  2013-10-28 22:16     ` Richard Weinberger
  0 siblings, 1 reply; 14+ messages in thread
From: Paul Moore @ 2013-10-28 21:53 UTC (permalink / raw)
  To: Richard Weinberger
  Cc: Andy Lutomirski, libseccomp-discuss, Will Drewry, Kees Cook,
	linux-kernel

On Thursday, October 24, 2013 09:55:57 PM Richard Weinberger wrote:
> On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net> 
wrote:
> > I'm looking at the seccomp code, the ARM entry code, and the
> > syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> > speak ARM assembly doesn't help.)  My basic question is: what happens
> > if an OABI syscall happens?
> > 
> > AFAICS, the syscall arguments for EABI are r0..r5, although their
> > ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
> > lost as to what it is.  The seccomp_bpf_load function won't load r6,
> > so there had better not be anything useful in there...  (Also, struct
> > seccomp_data will have issues with a seventh "argument".)
> > 
> > But what happens to the syscall number?  For an EABI syscall, it's in
> > r7.  For an OABI syscall, it's in the swi instruction and gets copied
> > to r7 on entry.  If a debugger changes r7, presumably the syscall
> > number changes.
> > 
> > Oddly, there are two different syscall tables.  The major differences
> > seem to be that some of the OABI entries have their argument order
> > changed.  But there's also a magic constant 0x900000 added to the
> > syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
> > it reflected in ucontext's r7?
> > 
> > I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> > AUDIT_ARCH_ARM.
> > 
> > Can any of you shed some light on this?  I don't have an ARM system I
> > can test on, but if one of you can point me at a decent QEMU image, I
> > can play around.
> 
> Maybe this helps:
> http://people.debian.org/~aurel32/qemu/armel/

Thanks for the pointer, although those images look quite old, has anyone done 
a refresh?

Also, on a related note, does anyone have any experience with any of the cheap 
PC-esque ARM boards/systems that are floating around?  I'm to the point of 
considering picking one up for libseccomp development if I can find one that 
supports a standard development environment, decently responsive, and is 
relatively cheap ... anyone?

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-24 21:14   ` Andy Lutomirski
@ 2013-10-28 22:02     ` Paul Moore
  2013-10-29 17:48       ` Will Drewry
  0 siblings, 1 reply; 14+ messages in thread
From: Paul Moore @ 2013-10-28 22:02 UTC (permalink / raw)
  To: libseccomp-discuss; +Cc: Andy Lutomirski, Will Drewry, linux-kernel

On Thursday, October 24, 2013 02:14:15 PM Andy Lutomirski wrote:
> On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@redhat.com> wrote:
> > On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
> >> I'm looking at the seccomp code, the ARM entry code, and the
> >> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> >> speak ARM assembly doesn't help.)
> > 
> > I suspect Kees, and perhaps Will, will be able to provide the best
> > answers, but my thoughts are below.
> > 
> >> My basic question is: what happens if an OABI syscall happens?
> > 
> > Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff
> > is EABI I don't think there is much reason to worry about OABI.  I know
> > this doesn't answer your question, but perhaps this provides some
> > context.
>
> Are you sure you don't support it?

Yep, I said libseccomp doesn't support it so we don't ;)

It may build and function to some extent, but I'm making no claims for OABI 
support; if someone tries it on a OABI system they do so as their own risk.

> What actually happens if someone writes an EABI program that issues an OABI
> syscall?  (I'm hoping that the syscall nr ends up offset by 0x900000, but
> I'm not sure.)

Like you, I expect there would be a syscall mismatch but I can't say for 
certain.

> >> AFAICS, the syscall arguments for EABI are r0..r5, although their
> >> ordering is a bit odd*.
> > 
> > Hmmm, that could complicate things a bit - do you know if they are put in
> > a more "standard" order by the time they are accessed in
> > seccomp_bpf_load() via task_pt_regs()?  If not, we likely need to come up
> > with some special handling in libseccomp to account for this.
> 
> I don't think that such a think is possible.  It depends on the
> signature of the particular syscall, and I don't know if there's any
> table of these things.

Oh, that's all sorts of awesome.

Well, at least in libseccomp we do have a syscall table for each arch so it 
should be possible to track what per-syscall fixups are needed (assuming some 
augmentation of our syscall table structures) and apply them at runtime.  The 
hard part is going to be determining what fixups are needed and recording them 
in the table.

Grrrrr.

> >> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> >> AUDIT_ARCH_ARM.
> > 
> > Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There
> > are similar issues with x32; not quite as bad as with ARM, but still ...
> 
> As long as the combination of AUDIT_ARCH and nr uniquely identifies a
> syscall and its ABI, life should be good.

Ha!  Life may be good, but the code to handle it was annoying* ;)

Largely because I made the assumption (which turned out to be a bad) that an 
AUDIT_ARCH_* value uniquely identified a single ABI.  Removing that assumption 
was both annoying and painful; the code still isn't very good in dealing with 
multiple ABIs sharing a single AUDIT_ARCH_* token but it works.

-- 
paul moore
security and virtualization @ redhat


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ARM seccomp filters and EABI/OABI
  2013-10-28 21:53   ` Paul Moore
@ 2013-10-28 22:16     ` Richard Weinberger
  2013-10-29 19:38       ` Paul Moore
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Weinberger @ 2013-10-28 22:16 UTC (permalink / raw)
  To: Paul Moore
  Cc: Andy Lutomirski, libseccomp-discuss, Will Drewry, Kees Cook,
	linux-kernel

Am 28.10.2013 22:53, schrieb Paul Moore:
> On Thursday, October 24, 2013 09:55:57 PM Richard Weinberger wrote:
>> On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net> 
> wrote:
>>> I'm looking at the seccomp code, the ARM entry code, and the
>>> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>>> speak ARM assembly doesn't help.)  My basic question is: what happens
>>> if an OABI syscall happens?
>>>
>>> AFAICS, the syscall arguments for EABI are r0..r5, although their
>>> ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
>>> lost as to what it is.  The seccomp_bpf_load function won't load r6,
>>> so there had better not be anything useful in there...  (Also, struct
>>> seccomp_data will have issues with a seventh "argument".)
>>>
>>> But what happens to the syscall number?  For an EABI syscall, it's in
>>> r7.  For an OABI syscall, it's in the swi instruction and gets copied
>>> to r7 on entry.  If a debugger changes r7, presumably the syscall
>>> number changes.
>>>
>>> Oddly, there are two different syscall tables.  The major differences
>>> seem to be that some of the OABI entries have their argument order
>>> changed.  But there's also a magic constant 0x900000 added to the
>>> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
>>> it reflected in ucontext's r7?
>>>
>>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>>> AUDIT_ARCH_ARM.
>>>
>>> Can any of you shed some light on this?  I don't have an ARM system I
>>> can test on, but if one of you can point me at a decent QEMU image, I
>>> can play around.
>>
>> Maybe this helps:
>> http://people.debian.org/~aurel32/qemu/armel/
> 
> Thanks for the pointer, although those images look quite old, has anyone done 
> a refresh?

You are free to run "apt-get upgrade" within the said images. :-)

Thanks,
//richard

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-28 22:02     ` Paul Moore
@ 2013-10-29 17:48       ` Will Drewry
  2013-10-29 18:33         ` Andy Lutomirski
  2013-10-29 20:11         ` Paul Moore
  0 siblings, 2 replies; 14+ messages in thread
From: Will Drewry @ 2013-10-29 17:48 UTC (permalink / raw)
  To: Paul Moore; +Cc: libseccomp-discuss, Andy Lutomirski, linux-kernel

On Mon, Oct 28, 2013 at 5:02 PM, Paul Moore <pmoore@redhat.com> wrote:
> On Thursday, October 24, 2013 02:14:15 PM Andy Lutomirski wrote:
>> On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@redhat.com> wrote:
>> > On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
>> >> I'm looking at the seccomp code, the ARM entry code, and the
>> >> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>> >> speak ARM assembly doesn't help.)
>> >
>> > I suspect Kees, and perhaps Will, will be able to provide the best
>> > answers, but my thoughts are below.
>> >
>> >> My basic question is: what happens if an OABI syscall happens?
>> >
>> > Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff
>> > is EABI I don't think there is much reason to worry about OABI.  I know
>> > this doesn't answer your question, but perhaps this provides some
>> > context.
>>
>> Are you sure you don't support it?
>
> Yep, I said libseccomp doesn't support it so we don't ;)
>
> It may build and function to some extent, but I'm making no claims for OABI
> support; if someone tries it on a OABI system they do so as their own risk.
>
>> What actually happens if someone writes an EABI program that issues an OABI
>> syscall?  (I'm hoping that the syscall nr ends up offset by 0x900000, but
>> I'm not sure.)
>
> Like you, I expect there would be a syscall mismatch but I can't say for
> certain.

It looks like entry-common.S masks off the 0x900000 so that the
numbers are the same, but the entry path is determined by the software
interrupt instruction (SWI) 8-bit immediate which indicates the type
(which it looks like is read by loading the address(-4) in the link
register).

http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S?a=arm#L420

Then it just swaps the call table if the immediate is non-zero and
uses the arg to call into the oabi version of the syscall table.

I don't think there's a clear way to detect if the oabi table has been
swapped in.  I think that the reason that the AUDIT_ARCH is the same
for OABI compat/not compat is that there is no argument ordering or
syscall numbering difference.  I'm not 100% though.

>> >> AFAICS, the syscall arguments for EABI are r0..r5, although their
>> >> ordering is a bit odd*.
>> >
>> > Hmmm, that could complicate things a bit - do you know if they are put in
>> > a more "standard" order by the time they are accessed in
>> > seccomp_bpf_load() via task_pt_regs()?  If not, we likely need to come up
>> > with some special handling in libseccomp to account for this.
>>
>> I don't think that such a think is possible.  It depends on the
>> signature of the particular syscall, and I don't know if there's any
>> table of these things.
>
> Oh, that's all sorts of awesome.
>
> Well, at least in libseccomp we do have a syscall table for each arch so it
> should be possible to track what per-syscall fixups are needed (assuming some
> augmentation of our syscall table structures) and apply them at runtime.  The
> hard part is going to be determining what fixups are needed and recording them
> in the table.
>
> Grrrrr.

>From looking at the oabi compat calls, it may be that no fixup is
really needed in the BPF side, but only in places where other argument
introspection occurs -- ptrace or sigsys handlers.

>> >> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>> >> AUDIT_ARCH_ARM.
>> >
>> > Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There
>> > are similar issues with x32; not quite as bad as with ARM, but still ...
>>
>> As long as the combination of AUDIT_ARCH and nr uniquely identifies a
>> syscall and its ABI, life should be good.
>
> Ha!  Life may be good, but the code to handle it was annoying* ;)
>
> Largely because I made the assumption (which turned out to be a bad) that an
> AUDIT_ARCH_* value uniquely identified a single ABI.  Removing that assumption
> was both annoying and painful; the code still isn't very good in dealing with
> multiple ABIs sharing a single AUDIT_ARCH_* token but it works.

It seems like a problem for the audit infrastucture if the calling
conventions are yielding improper system call information -- but I
don't think it is in this case (which is why it seemed to make sense
to connect the two subsystems...).  The calls don't seem different,
but the structs are organized, aligned, or padded differently (which
shouldn't matter _too_ much to the seccomp filter unless the arg
ordering is different, etc).  Bleh.
[ http://lxr.free-electrons.com/source/arch/arm/kernel/sys_oabi-compat.c ]

I'm not sure if pt_regs ends up looking the same, but I was hoping it
did.  I realize that the seventh argument is dropped for OABI, but
IIRC, the only call that used it was the syscall() syscall:

  http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S#L524

which is marked as obsolete in calls.S.  I don't think any other OABI
calls (or any other calls in general) pass a seventh argument. *think*
is the operative word though.

Maybe someone who's a bit more confident with the ARM syscall path can weigh in!

> Also, on a related note, does anyone have any experience with any of the cheap
> PC-esque ARM boards/systems that are floating around?  I'm to the point of
> considering picking one up for libseccomp development if I can find one that
> supports a standard development environment, decently responsive, and is
> relatively cheap ... anyone?

I might have a spare, not-too-old board around - I'll take a look.

cheers!
will

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-29 17:48       ` Will Drewry
@ 2013-10-29 18:33         ` Andy Lutomirski
  2013-10-29 20:11         ` Paul Moore
  1 sibling, 0 replies; 14+ messages in thread
From: Andy Lutomirski @ 2013-10-29 18:33 UTC (permalink / raw)
  To: Will Drewry; +Cc: Paul Moore, libseccomp-discuss, linux-kernel

On Tue, Oct 29, 2013 at 10:48 AM, Will Drewry <wad@chromium.org> wrote:
> On Mon, Oct 28, 2013 at 5:02 PM, Paul Moore <pmoore@redhat.com> wrote:
>> On Thursday, October 24, 2013 02:14:15 PM Andy Lutomirski wrote:
>>> On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@redhat.com> wrote:
>>> > On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
>>> >> I'm looking at the seccomp code, the ARM entry code, and the
>>> >> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>>> >> speak ARM assembly doesn't help.)
>>> >
>>> > I suspect Kees, and perhaps Will, will be able to provide the best
>>> > answers, but my thoughts are below.
>>> >
>>> >> My basic question is: what happens if an OABI syscall happens?
>>> >
>>> > Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff
>>> > is EABI I don't think there is much reason to worry about OABI.  I know
>>> > this doesn't answer your question, but perhaps this provides some
>>> > context.
>>>
>>> Are you sure you don't support it?
>>
>> Yep, I said libseccomp doesn't support it so we don't ;)
>>
>> It may build and function to some extent, but I'm making no claims for OABI
>> support; if someone tries it on a OABI system they do so as their own risk.
>>
>>> What actually happens if someone writes an EABI program that issues an OABI
>>> syscall?  (I'm hoping that the syscall nr ends up offset by 0x900000, but
>>> I'm not sure.)
>>
>> Like you, I expect there would be a syscall mismatch but I can't say for
>> certain.
>
> It looks like entry-common.S masks off the 0x900000 so that the
> numbers are the same, but the entry path is determined by the software
> interrupt instruction (SWI) 8-bit immediate which indicates the type
> (which it looks like is read by loading the address(-4) in the link
> register).
>
> http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S?a=arm#L420
>
> Then it just swaps the call table if the immediate is non-zero and
> uses the arg to call into the oabi version of the syscall table.
>
> I don't think there's a clear way to detect if the oabi table has been
> swapped in.  I think that the reason that the AUDIT_ARCH is the same
> for OABI compat/not compat is that there is no argument ordering or
> syscall numbering difference.  I'm not 100% though.
>
>>> >> AFAICS, the syscall arguments for EABI are r0..r5, although their
>>> >> ordering is a bit odd*.
>>> >
>>> > Hmmm, that could complicate things a bit - do you know if they are put in
>>> > a more "standard" order by the time they are accessed in
>>> > seccomp_bpf_load() via task_pt_regs()?  If not, we likely need to come up
>>> > with some special handling in libseccomp to account for this.
>>>
>>> I don't think that such a think is possible.  It depends on the
>>> signature of the particular syscall, and I don't know if there's any
>>> table of these things.
>>
>> Oh, that's all sorts of awesome.
>>
>> Well, at least in libseccomp we do have a syscall table for each arch so it
>> should be possible to track what per-syscall fixups are needed (assuming some
>> augmentation of our syscall table structures) and apply them at runtime.  The
>> hard part is going to be determining what fixups are needed and recording them
>> in the table.
>>
>> Grrrrr.
>
> From looking at the oabi compat calls, it may be that no fixup is
> really needed in the BPF side, but only in places where other argument
> introspection occurs -- ptrace or sigsys handlers.

Isn't a fixup needed for things like oabi_pread64 if the filter tries
to load the arguments?

If it's indeed the case that the nr has the 0x900000 masked off from
the syscall nr, I'd argue that that's a security bug -- a compromised
EABI process could (assuming it can find the right instruction in
executable memory) issue an OABI call to try to confuse the filter.
(Actually, executable memory might not be needed -- for all I know,
ARM code can spoof the link register.)  Alternatively, banning OABI
calls outright when seccomp is enabled might not be such a bad idea.

>
>>> >> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>>> >> AUDIT_ARCH_ARM.
>>> >
>>> > Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There
>>> > are similar issues with x32; not quite as bad as with ARM, but still ...
>>>
>>> As long as the combination of AUDIT_ARCH and nr uniquely identifies a
>>> syscall and its ABI, life should be good.
>>
>> Ha!  Life may be good, but the code to handle it was annoying* ;)
>>
>> Largely because I made the assumption (which turned out to be a bad) that an
>> AUDIT_ARCH_* value uniquely identified a single ABI.  Removing that assumption
>> was both annoying and painful; the code still isn't very good in dealing with
>> multiple ABIs sharing a single AUDIT_ARCH_* token but it works.
>
> It seems like a problem for the audit infrastucture if the calling
> conventions are yielding improper system call information -- but I
> don't think it is in this case (which is why it seemed to make sense
> to connect the two subsystems...).  The calls don't seem different,
> but the structs are organized, aligned, or padded differently (which
> shouldn't matter _too_ much to the seccomp filter unless the arg
> ordering is different, etc).  Bleh.
> [ http://lxr.free-electrons.com/source/arch/arm/kernel/sys_oabi-compat.c ]
>
> I'm not sure if pt_regs ends up looking the same, but I was hoping it
> did.  I realize that the seventh argument is dropped for OABI, but
> IIRC, the only call that used it was the syscall() syscall:
>
>   http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S#L524
>
> which is marked as obsolete in calls.S.  I don't think any other OABI
> calls (or any other calls in general) pass a seventh argument. *think*
> is the operative word though.

Good find.  I didn't realize that anything used the seventh argument.
sys_syscall is probably completely useless for EABI, though --
userspace can issue a syscall by number the same way it would on any
other (sane) architecture.  I can see why it's useful for OABI,
though.

--Andy

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ARM seccomp filters and EABI/OABI
  2013-10-28 22:16     ` Richard Weinberger
@ 2013-10-29 19:38       ` Paul Moore
  2013-10-31 23:50         ` Andy Lutomirski
  0 siblings, 1 reply; 14+ messages in thread
From: Paul Moore @ 2013-10-29 19:38 UTC (permalink / raw)
  To: Richard Weinberger
  Cc: Andy Lutomirski, libseccomp-discuss, Will Drewry, Kees Cook,
	linux-kernel

On Monday, October 28, 2013 11:16:20 PM Richard Weinberger wrote:
> Am 28.10.2013 22:53, schrieb Paul Moore:
> > On Thursday, October 24, 2013 09:55:57 PM Richard Weinberger wrote:
> >> On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net>
> > 
> > wrote:
> >>> I'm looking at the seccomp code, the ARM entry code, and the
> >>> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> >>> speak ARM assembly doesn't help.)  My basic question is: what happens
> >>> if an OABI syscall happens?
> >>> 
> >>> AFAICS, the syscall arguments for EABI are r0..r5, although their
> >>> ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
> >>> lost as to what it is.  The seccomp_bpf_load function won't load r6,
> >>> so there had better not be anything useful in there...  (Also, struct
> >>> seccomp_data will have issues with a seventh "argument".)
> >>> 
> >>> But what happens to the syscall number?  For an EABI syscall, it's in
> >>> r7.  For an OABI syscall, it's in the swi instruction and gets copied
> >>> to r7 on entry.  If a debugger changes r7, presumably the syscall
> >>> number changes.
> >>> 
> >>> Oddly, there are two different syscall tables.  The major differences
> >>> seem to be that some of the OABI entries have their argument order
> >>> changed.  But there's also a magic constant 0x900000 added to the
> >>> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
> >>> it reflected in ucontext's r7?
> >>> 
> >>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> >>> AUDIT_ARCH_ARM.
> >>> 
> >>> Can any of you shed some light on this?  I don't have an ARM system I
> >>> can test on, but if one of you can point me at a decent QEMU image, I
> >>> can play around.
> >> 
> >> Maybe this helps:
> >> http://people.debian.org/~aurel32/qemu/armel/
> > 
> > Thanks for the pointer, although those images look quite old, has anyone
> > done a refresh?
> 
> You are free to run "apt-get upgrade" within the said images. :-)

Okay, true ;)

-- 
paul moore
www.paul-moore.com


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-29 17:48       ` Will Drewry
  2013-10-29 18:33         ` Andy Lutomirski
@ 2013-10-29 20:11         ` Paul Moore
  1 sibling, 0 replies; 14+ messages in thread
From: Paul Moore @ 2013-10-29 20:11 UTC (permalink / raw)
  To: Will Drewry; +Cc: libseccomp-discuss, Andy Lutomirski, linux-kernel

On Tuesday, October 29, 2013 12:48:45 PM Will Drewry wrote:
> On Mon, Oct 28, 2013 at 5:02 PM, Paul Moore <pmoore@redhat.com> wrote:
> > On Thursday, October 24, 2013 02:14:15 PM Andy Lutomirski wrote:
> >> On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@redhat.com> wrote:
> >> > On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
> >> >> I'm looking at the seccomp code, the ARM entry code, and the
> >> >> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
> >> >> speak ARM assembly doesn't help.)
> >> > 
> >> > I suspect Kees, and perhaps Will, will be able to provide the best
> >> > answers, but my thoughts are below.
> >> > 
> >> >> My basic question is: what happens if an OABI syscall happens?
> >> > 
> >> > Well, libseccomp doesn't support ARM OABI and since all the new ARM
> >> > stuff is EABI I don't think there is much reason to worry about OABI. 
> >> > I know this doesn't answer your question, but perhaps this provides
> >> > some context.
> >> 
> >> Are you sure you don't support it?
> > 
> > Yep, I said libseccomp doesn't support it so we don't ;)
> > 
> > It may build and function to some extent, but I'm making no claims for
> > OABI support; if someone tries it on a OABI system they do so as their own
> > risk.
> > 
> >> What actually happens if someone writes an EABI program that issues an
> >> OABI syscall?  (I'm hoping that the syscall nr ends up offset by
> >> 0x900000, but I'm not sure.)
> > 
> > Like you, I expect there would be a syscall mismatch but I can't say for
> > certain.
> 
> It looks like entry-common.S masks off the 0x900000 so that the
> numbers are the same, but the entry path is determined by the software
> interrupt instruction (SWI) 8-bit immediate which indicates the type
> (which it looks like is read by loading the address(-4) in the link
> register).
> 
> http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S?a=arm#L4
> 20
> 
> Then it just swaps the call table if the immediate is non-zero and
> uses the arg to call into the oabi version of the syscall table.
> 
> I don't think there's a clear way to detect if the oabi table has been
> swapped in.  I think that the reason that the AUDIT_ARCH is the same
> for OABI compat/not compat is that there is no argument ordering or
> syscall numbering difference.  I'm not 100% though.

I'm now also suspicious of what ends up being returned from syscall_get_nr(), 
is the 0x900000 masked out for OABI or not?  We had a similar problem with the 
x32 stuff and had to fix the kernel to get things working correctly.

> >> >> AFAICS, the syscall arguments for EABI are r0..r5, although their
> >> >> ordering is a bit odd*.
> >> > 
> >> > Hmmm, that could complicate things a bit - do you know if they are put
> >> > in a more "standard" order by the time they are accessed in
> >> > seccomp_bpf_load() via task_pt_regs()?  If not, we likely need to come
> >> > up with some special handling in libseccomp to account for this.
> >> 
> >> I don't think that such a think is possible.  It depends on the
> >> signature of the particular syscall, and I don't know if there's any
> >> table of these things.
> > 
> > Oh, that's all sorts of awesome.
> > 
> > Well, at least in libseccomp we do have a syscall table for each arch so
> > it should be possible to track what per-syscall fixups are needed
> > (assuming some augmentation of our syscall table structures) and apply
> > them at runtime.  The hard part is going to be determining what fixups are
> > needed and recording them in the table.
> > 
> > Grrrrr.
> 
> From looking at the oabi compat calls, it may be that no fixup is
> really needed in the BPF side, but only in places where other argument
> introspection occurs -- ptrace or sigsys handlers.

Better I suppose, still not great.  It frees us up a bit from needing to do in 
special ARM handling when generating the filter, but it does make it harder to 
do the stuff that Andy is trying to do.

> >> >> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
> >> >> AUDIT_ARCH_ARM.
> >> > 
> >> > Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There
> >> > are similar issues with x32; not quite as bad as with ARM, but still
> >> > ...
> >> 
> >> As long as the combination of AUDIT_ARCH and nr uniquely identifies a
> >> syscall and its ABI, life should be good.
> > 
> > Ha!  Life may be good, but the code to handle it was annoying* ;)
> > 
> > Largely because I made the assumption (which turned out to be a bad) that
> > an AUDIT_ARCH_* value uniquely identified a single ABI.  Removing that
> > assumption was both annoying and painful; the code still isn't very good
> > in dealing with multiple ABIs sharing a single AUDIT_ARCH_* token but it
> > works.
> 
> It seems like a problem for the audit infrastucture if the calling
> conventions are yielding improper system call information -- but I
> don't think it is in this case (which is why it seemed to make sense
> to connect the two subsystems...).

The problem I've been bumping into with libseccomp is that the AUDIT_ARCH_* 
values are really only useful in pointing you at the right syscall table, and 
not necessarily the ABI.  The x86_64/x32 (and possibly ARM OABI/EABI) issue is 
a good example of this limitation.  I suppose for audit this may not be a 
major concern, but when you are writing a seccomp BPF filter and you want to 
allow x86_64 but not x32 you have to examine both the AUDIT_ARCH_* value and 
the syscall number, looking at the AUDIT_ARCH_* value is not sufficient.

> The calls don't seem different, but the structs are organized, aligned, or
> padded differently (which shouldn't matter _too_ much to the seccomp filter
> unless the arg ordering is different, etc).  Bleh.
> [ http://lxr.free-electrons.com/source/arch/arm/kernel/sys_oabi-compat.c ]

That's a pretty strong argument for not supporting ARM OABI in libseccomp, 
especially since everything seems to be going towards EABI.

> I'm not sure if pt_regs ends up looking the same, but I was hoping it
> did.  I realize that the seventh argument is dropped for OABI, but
> IIRC, the only call that used it was the syscall() syscall:
> 
>   http://lxr.free-electrons.com/source/arch/arm/kernel/entry-common.S#L524
> 
> which is marked as obsolete in calls.S.  I don't think any other OABI
> calls (or any other calls in general) pass a seventh argument. *think*
> is the operative word though.
> 
> Maybe someone who's a bit more confident with the ARM syscall path can weigh
> in!
>
> > Also, on a related note, does anyone have any experience with any of the
> > cheap PC-esque ARM boards/systems that are floating around?  I'm to the
> > point of considering picking one up for libseccomp development if I can
> > find one that supports a standard development environment, decently
> > responsive, and is relatively cheap ... anyone?
> 
> I might have a spare, not-too-old board around - I'll take a look.

That would be great, but I was really just looking for recommendations.  I 
don't mind buying some ARM hardware, I just would like to find something that 
I can treat like a normal PC (or close to it), e.g. limited bootloader hacks 
needed, SATA port, working display, network, etc.

-- 
paul moore
security and virtualization @ redhat


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [libseccomp-discuss] ARM seccomp filters and EABI/OABI
  2013-10-24 19:11 ` [libseccomp-discuss] " Paul Moore
  2013-10-24 21:14   ` Andy Lutomirski
@ 2013-10-30 17:19   ` Kees Cook
  1 sibling, 0 replies; 14+ messages in thread
From: Kees Cook @ 2013-10-30 17:19 UTC (permalink / raw)
  To: Paul Moore; +Cc: libseccomp-discuss, Andy Lutomirski, Will Drewry, linux-kernel

On Thu, Oct 24, 2013 at 12:11 PM, Paul Moore <pmoore@redhat.com> wrote:
> On Wednesday, October 23, 2013 02:02:00 PM Andy Lutomirski wrote:
>> I'm looking at the seccomp code, the ARM entry code, and the
>> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>> speak ARM assembly doesn't help.)
>
> I suspect Kees, and perhaps Will, will be able to provide the best answers,
> but my thoughts are below.
>
>> My basic question is: what happens if an OABI syscall happens?
>
> Well, libseccomp doesn't support ARM OABI and since all the new ARM stuff is
> EABI I don't think there is much reason to worry about OABI.  I know this
> doesn't answer your question, but perhaps this provides some context.

The original ARM seccomp patch had two SECCOMP_ARCH entries, but it
was a mistake as it was really a description of endianness:
https://lkml.org/lkml/2012/11/5/273

I also got the impression from another discussion I can't find that
when seccomp does its checks, the syscall offset has already been
dealt with. The best I could find discussing this was:
https://lkml.org/lkml/2012/11/1/383

>> AFAICS, the syscall arguments for EABI are r0..r5, although their
>> ordering is a bit odd*.
>
> Hmmm, that could complicate things a bit - do you know if they are put in a
> more "standard" order by the time they are accessed in seccomp_bpf_load() via
> task_pt_regs()?  If not, we likely need to come up with some special handling
> in libseccomp to account for this.
>
>> For OABI, r6 seems to play some role, but I'm
>> lost as to what it is.  The seccomp_bpf_load function won't load r6,
>> so there had better not be anything useful in there...  (Also, struct
>> seccomp_data will have issues with a seventh "argument".)
>>
>> But what happens to the syscall number?  For an EABI syscall, it's in
>> r7.  For an OABI syscall, it's in the swi instruction and gets copied
>> to r7 on entry.  If a debugger changes r7, presumably the syscall
>> number changes.
>>
>> Oddly, there are two different syscall tables.  The major differences
>> seem to be that some of the OABI entries have their argument order
>> changed.  But there's also a magic constant 0x900000 added to the
>> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
>> it reflected in ucontext's r7?
>
> Thankfully, I've been able to ignore most of this.
>
>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>> AUDIT_ARCH_ARM.
>
> Yeah, the usage of AUDIT_ARCH_* is not really ideal for seccomp.  There are
> similar issues with x32; not quite as bad as with ARM, but still ...
>
>> Can any of you shed some light on this?  I don't have an ARM system I
>> can test on, but if one of you can point me at a decent QEMU image, I
>> can play around.
>
> I know Kees had one at one point, although I remember him commenting that it
> was painfully slow under QEMU.

Yeah, I set up an ARM emulator via QEMU. It is very slow, but it at
least gets me somewhere with testing when I don't have a real ARM
device handy. I followed the Debian ARM qemu instructions.

-Kees

-- 
Kees Cook
Chrome OS Security

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ARM seccomp filters and EABI/OABI
  2013-10-29 19:38       ` Paul Moore
@ 2013-10-31 23:50         ` Andy Lutomirski
  2013-11-01  7:45           ` Kees Cook
  0 siblings, 1 reply; 14+ messages in thread
From: Andy Lutomirski @ 2013-10-31 23:50 UTC (permalink / raw)
  To: Paul Moore
  Cc: Richard Weinberger, libseccomp-discuss, Will Drewry, Kees Cook,
	linux-kernel

On Tue, Oct 29, 2013 at 12:38 PM, Paul Moore <paul@paul-moore.com> wrote:
> On Monday, October 28, 2013 11:16:20 PM Richard Weinberger wrote:
>> Am 28.10.2013 22:53, schrieb Paul Moore:
>> > On Thursday, October 24, 2013 09:55:57 PM Richard Weinberger wrote:
>> >> On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net>
>> >
>> > wrote:
>> >>> I'm looking at the seccomp code, the ARM entry code, and the
>> >>> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>> >>> speak ARM assembly doesn't help.)  My basic question is: what happens
>> >>> if an OABI syscall happens?
>> >>>
>> >>> AFAICS, the syscall arguments for EABI are r0..r5, although their
>> >>> ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
>> >>> lost as to what it is.  The seccomp_bpf_load function won't load r6,
>> >>> so there had better not be anything useful in there...  (Also, struct
>> >>> seccomp_data will have issues with a seventh "argument".)
>> >>>
>> >>> But what happens to the syscall number?  For an EABI syscall, it's in
>> >>> r7.  For an OABI syscall, it's in the swi instruction and gets copied
>> >>> to r7 on entry.  If a debugger changes r7, presumably the syscall
>> >>> number changes.
>> >>>
>> >>> Oddly, there are two different syscall tables.  The major differences
>> >>> seem to be that some of the OABI entries have their argument order
>> >>> changed.  But there's also a magic constant 0x900000 added to the
>> >>> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
>> >>> it reflected in ucontext's r7?
>> >>>
>> >>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>> >>> AUDIT_ARCH_ARM.
>> >>>
>> >>> Can any of you shed some light on this?  I don't have an ARM system I
>> >>> can test on, but if one of you can point me at a decent QEMU image, I
>> >>> can play around.
>> >>
>> >> Maybe this helps:
>> >> http://people.debian.org/~aurel32/qemu/armel/
>> >
>> > Thanks for the pointer, although those images look quite old, has anyone
>> > done a refresh?
>>
>> You are free to run "apt-get upgrade" within the said images. :-)
>
> Okay, true ;)

Except it didn't work...  I fixed it with 'apt-key adv --recv-keys
--keyserver keyserver.ubuntu.com <key id from update's error
message>'.

I have yet to build a working kernel for this thing, though.
Apparently kernels since 3.8 have something wrong in the "versatile"
board file.  Do any of you have a working .config and qemu -M option?

>
> --
> paul moore
> www.paul-moore.com
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ARM seccomp filters and EABI/OABI
  2013-10-31 23:50         ` Andy Lutomirski
@ 2013-11-01  7:45           ` Kees Cook
  0 siblings, 0 replies; 14+ messages in thread
From: Kees Cook @ 2013-11-01  7:45 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Paul Moore, Richard Weinberger, libseccomp-discuss, Will Drewry,
	linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]

On Thu, Oct 31, 2013 at 11:50 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Oct 29, 2013 at 12:38 PM, Paul Moore <paul@paul-moore.com> wrote:
>> On Monday, October 28, 2013 11:16:20 PM Richard Weinberger wrote:
>>> Am 28.10.2013 22:53, schrieb Paul Moore:
>>> > On Thursday, October 24, 2013 09:55:57 PM Richard Weinberger wrote:
>>> >> On Wed, Oct 23, 2013 at 11:02 PM, Andy Lutomirski <luto@amacapital.net>
>>> >
>>> > wrote:
>>> >>> I'm looking at the seccomp code, the ARM entry code, and the
>>> >>> syscall(2) manpage, and I'm a bit lost.  (The fact that I don't really
>>> >>> speak ARM assembly doesn't help.)  My basic question is: what happens
>>> >>> if an OABI syscall happens?
>>> >>>
>>> >>> AFAICS, the syscall arguments for EABI are r0..r5, although their
>>> >>> ordering is a bit odd*.  For OABI, r6 seems to play some role, but I'm
>>> >>> lost as to what it is.  The seccomp_bpf_load function won't load r6,
>>> >>> so there had better not be anything useful in there...  (Also, struct
>>> >>> seccomp_data will have issues with a seventh "argument".)
>>> >>>
>>> >>> But what happens to the syscall number?  For an EABI syscall, it's in
>>> >>> r7.  For an OABI syscall, it's in the swi instruction and gets copied
>>> >>> to r7 on entry.  If a debugger changes r7, presumably the syscall
>>> >>> number changes.
>>> >>>
>>> >>> Oddly, there are two different syscall tables.  The major differences
>>> >>> seem to be that some of the OABI entries have their argument order
>>> >>> changed.  But there's also a magic constant 0x900000 added to the
>>> >>> syscall number somewhere -- is it reflected in _sigsys._syscall?  Is
>>> >>> it reflected in ucontext's r7?
>>> >>>
>>> >>> I'm a bit surprised to see that both the EABI and OABI ABIs show up as
>>> >>> AUDIT_ARCH_ARM.
>>> >>>
>>> >>> Can any of you shed some light on this?  I don't have an ARM system I
>>> >>> can test on, but if one of you can point me at a decent QEMU image, I
>>> >>> can play around.
>>> >>
>>> >> Maybe this helps:
>>> >> http://people.debian.org/~aurel32/qemu/armel/
>>> >
>>> > Thanks for the pointer, although those images look quite old, has anyone
>>> > done a refresh?
>>>
>>> You are free to run "apt-get upgrade" within the said images. :-)
>>
>> Okay, true ;)
>
> Except it didn't work...  I fixed it with 'apt-key adv --recv-keys
> --keyserver keyserver.ubuntu.com <key id from update's error
> message>'.
>
> I have yet to build a working kernel for this thing, though.
> Apparently kernels since 3.8 have something wrong in the "versatile"
> board file.  Do any of you have a working .config and qemu -M option?

For qemu before 1.5, I needed to revert
f9b71fef12f0d6ac5c7051cfd87f7700f78c56b6 to get SCSI working again.
I've attached my .config. I launch with:

sudo qemu-system-arm -nographic -m 256 -M versatilepb \
    -kernel $HOME/Code/linux/arch/arm/boot/zImage \
    -drive file=$DIR/vda.qcow2,if=scsi,format=qcow2 \
    -net nic,vlan=0 -net
tap,vlan=0,script=$HOME/kvm/kvm-ifup,downscript=$HOME/kvm/kvm-ifdown,ifname=tap-$IMG
\
    -monitor tcp:127.0.0.1:8087,server,nowait \
    -append "loglevel=8 debug root=/dev/sda1 slub_debug=FZ console=ttyAMA0 $@"

I can send the if-up/down scripts if you want them too.

-Kees

-- 
Kees Cook
Chrome OS Security

[-- Attachment #2: config.arm --]
[-- Type: application/octet-stream, Size: 53585 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.9.0-rc5 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_ALWAYS_USE_PERSISTENT_CLOCK is not set
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y

#
# Timers subsystem
#
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_RCU_STALL_COMMON is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_CGROUPS is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EXPERT is not set
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
# CONFIG_COMPAT_BRK is not set
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
CONFIG_ARCH_VERSATILE=y
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_MXS is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_NOMADIK is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Versatile platform type
#
CONFIG_ARCH_VERSATILE_PB=y
CONFIG_MACH_VERSATILE_AB=y
CONFIG_MACH_VERSATILE_DT=y
CONFIG_PLAT_VERSATILE_CLOCK=y
CONFIG_PLAT_VERSATILE_CLCD=y
CONFIG_PLAT_VERSATILE_SCHED_CLOCK=y
CONFIG_PLAT_VERSATILE=y
CONFIG_ARM_TIMER_SP804=y

#
# Processor Type
#
CONFIG_CPU_ARM926T=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5TJ=y
CONFIG_CPU_PABRT_LEGACY=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_WRITETHROUGH is not set
# CONFIG_CPU_CACHE_ROUND_ROBIN is not set
# CONFIG_CACHE_L2X0 is not set
CONFIG_ARM_L1_CACHE_SHIFT=5
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
CONFIG_ICST=y

#
# Bus support
#
CONFIG_ARM_AMBA=y
CONFIG_PCI=y
CONFIG_PCI_SYSCALL=y
# CONFIG_PCI_DEBUG is not set
CONFIG_PCI_REALLOC_ENABLE_AUTO=y
CONFIG_PCI_STUB=y
# CONFIG_PCI_IOV is not set
# CONFIG_PCI_PRI is not set
# CONFIG_PCI_PASID is not set
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
# CONFIG_YENTA is not set
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set

#
# Kernel Features
#
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_NR_GPIO=0
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_HZ=100
# CONFIG_SCHED_HRTICK is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_NEED_PER_CPU_KM=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
CONFIG_SECCOMP=y
CONFIG_CC_STACKPROTECTOR=y

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE="root=1f03 mem=32M"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set

#
# CPU Power Management
#
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_FPE_NWFPE=y
# CONFIG_FPE_NWFPE_XP is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_NET_IPVTI is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_NETLABEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
# CONFIG_CMA is not set

#
# Bus devices
#
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_GEOMETRY is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_CFI_STAA is not set
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
CONFIG_MTD_PHYSMAP=y
# CONFIG_MTD_PHYSMAP_COMPAT is not set
# CONFIG_MTD_PHYSMAP_OF is not set
# CONFIG_MTD_INTEL_VR_NOR is not set
# CONFIG_MTD_PLATRAM is not set
# CONFIG_MTD_PISMO is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
# CONFIG_MTD_NAND is not set
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_PCI=y
CONFIG_OF_PCI_IRQ=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_BLK_DEV_SX8 is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_PHANTOM is not set
# CONFIG_INTEL_MID_PTI is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_ARM_CHARLCD is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_PCH_PHUB is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
CONFIG_EEPROM_LEGACY=m
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_SCSI_BNX2X_FCOE is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_HPSA is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_MVUMI is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_FCOE is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_BFA_FC is not set
# CONFIG_SCSI_VIRTIO is not set
# CONFIG_SCSI_CHELSIO_FCOE is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_SATA_ACARD_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_SX4 is not set
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_HIGHBANK is not set
CONFIG_SATA_MV=y
# CONFIG_SATA_NV is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SCH is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_RAID is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_VIRTIO_NET is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
CONFIG_NET_VENDOR_ADAPTEC=y
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
# CONFIG_PCMCIA_NMCLAN is not set
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2X is not set
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_NET_VENDOR_CIRRUS=y
# CONFIG_CS89x0 is not set
CONFIG_NET_VENDOR_CISCO=y
# CONFIG_ENIC is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DEC=y
# CONFIG_NET_TULIP is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
CONFIG_NET_VENDOR_FARADAY=y
# CONFIG_FTMAC100 is not set
# CONFIG_FTGMAC100 is not set
CONFIG_NET_VENDOR_FUJITSU=y
# CONFIG_PCMCIA_FMVJ18X is not set
CONFIG_NET_VENDOR_HP=y
# CONFIG_HP100 is not set
CONFIG_NET_VENDOR_INTEL=y
# CONFIG_E100 is not set
# CONFIG_E1000 is not set
# CONFIG_E1000E is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_IXGB is not set
# CONFIG_IXGBE is not set
CONFIG_NET_VENDOR_I825XX=y
# CONFIG_IP1000 is not set
# CONFIG_JME is not set
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
# CONFIG_KSZ884X_PCI is not set
CONFIG_NET_VENDOR_MYRI=y
# CONFIG_MYRI10GE is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
# CONFIG_NATSEMI is not set
# CONFIG_NS83820 is not set
CONFIG_NET_VENDOR_8390=y
# CONFIG_PCMCIA_AXNET is not set
# CONFIG_AX88796 is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_PCMCIA_PCNET is not set
CONFIG_NET_VENDOR_NVIDIA=y
# CONFIG_FORCEDETH is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
# CONFIG_ETHOC is not set
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
# CONFIG_QLGE is not set
# CONFIG_NETXEN_NIC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_R8169 is not set
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SILAN=y
# CONFIG_SC92031 is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
# CONFIG_SIS190 is not set
# CONFIG_SFC is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_SMC91X=y
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMC911X is not set
# CONFIG_SMSC911X is not set
# CONFIG_SMSC9420 is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_SUN=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NIU is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TLAN is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_NET_VENDOR_XIRCOM=y
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PHYLIB is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_ATMEL is not set
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PRISM54 is not set
# CONFIG_HOSTAP is not set
# CONFIG_WL_TI is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
# CONFIG_SERIO_SERPORT is not set
CONFIG_SERIO_AMBAKMI=y
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=16
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_PCI=m
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set
# CONFIG_SERIAL_8250_EM is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_OF_PLATFORM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_HVC_DCC is not set
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
CONFIG_HW_RANDOM_VIRTIO=y
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=m
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_INTEL_MID is not set
# CONFIG_I2C_NOMADIK is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_VERSATILE is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
# CONFIG_PPS is not set

#
# PPS generators support
#

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_LPC_SCH is not set
# CONFIG_LPC_ICH is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_OF_DISPLAY_TIMING is not set
# CONFIG_OF_VIDEOMODE is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_WMT_GE_ROPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
CONFIG_FB_ARMCLCD=y
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GOLDFISH is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
CONFIG_FONT_ACORN_8x8=y
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_LOGO is not set
# CONFIG_SOUND is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
# CONFIG_USB is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_OMAP_USB3 is not set
# CONFIG_OMAP_CONTROL_USB is not set
# CONFIG_USB_GADGET is not set

#
# OTG and related infrastructure
#
# CONFIG_UWB is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_ARMMMCI=m
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MMC_SDRICOH_CS is not set
# CONFIG_MMC_CB710 is not set
# CONFIG_MMC_VIA_SDMMC is not set
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_VIRTIO_MMIO=y
# CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_MACH_CLKDEV=y

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_MMIO=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
CONFIG_VIRT_DRIVERS=y
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_VIC=y
CONFIG_ARM_VIC_NR=2
CONFIG_VERSATILE_FPGA_IRQ=y
CONFIG_VERSATILE_FPGA_IRQ_NR=4
# CONFIG_IPACK_BUS is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=m
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_QUOTACTL is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
# CONFIG_MSDOS_FS is not set
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_LOGFS is not set
CONFIG_CRAMFS=y
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
CONFIG_ROMFS_FS=y
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_SWAP is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
# CONFIG_NFSD_V4 is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set

#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_DEBUG_SLAB is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set

#
# RCU Debugging
#
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_ENABLE_DEFAULT_TRACERS is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_PROBE_EVENTS is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
CONFIG_DEBUG_USER=y
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_EARLY_PRINTK is not set
# CONFIG_OC_ETM is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_PATH=y
# CONFIG_SECURITY_SELINUX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
CONFIG_SECURITY_YAMA=y
CONFIG_SECURITY_YAMA_STACKED=y
# CONFIG_IMA is not set
CONFIG_DEFAULT_SECURITY_APPARMOR=y
# CONFIG_DEFAULT_SECURITY_YAMA is not set
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="apparmor"
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_HIFN_795X is not set
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
# CONFIG_CRC8 is not set
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2013-11-01  7:45 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-23 21:02 ARM seccomp filters and EABI/OABI Andy Lutomirski
2013-10-24 19:11 ` [libseccomp-discuss] " Paul Moore
2013-10-24 21:14   ` Andy Lutomirski
2013-10-28 22:02     ` Paul Moore
2013-10-29 17:48       ` Will Drewry
2013-10-29 18:33         ` Andy Lutomirski
2013-10-29 20:11         ` Paul Moore
2013-10-30 17:19   ` Kees Cook
2013-10-24 19:55 ` Richard Weinberger
2013-10-28 21:53   ` Paul Moore
2013-10-28 22:16     ` Richard Weinberger
2013-10-29 19:38       ` Paul Moore
2013-10-31 23:50         ` Andy Lutomirski
2013-11-01  7:45           ` Kees Cook

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).