On Thu, Sep 24, 2020 at 2:37 PM David Laight wrote:
> From: Jann Horn
> > Sent: 24 September 2020 13:29
> ...
> > I think our goal here should be that if a syscall is always allowed,
> > seccomp should execute the smallest amount of instructions we can get
> > away with, and touch the smallest amo
From: Jann Horn
> Sent: 24 September 2020 13:29
...
> I think our goal here should be that if a syscall is always allowed,
> seccomp should execute the smallest amount of instructions we can get
> away with, and touch the smallest amount of memory possible (and
> preferably that memory should be sh
On Thu, Sep 24, 2020 at 9:37 AM Kees Cook wrote:
> On Thu, Sep 24, 2020 at 02:25:03AM +0200, Jann Horn wrote:
> > On Thu, Sep 24, 2020 at 1:29 AM Kees Cook wrote:
[...]
> > (However, a "which syscalls have a fixed result" bitmap might make
> > sense if we want to export the list of permitted sysc
On Thu, Sep 24, 2020 at 3:15 AM Kees Cook wrote:
> I was trying to be helpful: you hadn't seen the RFC, and it was missing
> the emulator piece, which I wanted to be small, so I put got it out the
> door today. I didn't want you to think you needed to port the larger
> emulator over, for example.
On Thu, Sep 24, 2020 at 03:07:23AM -0500, YiFei Zhu wrote:
> On Thu, Sep 24, 2020 at 2:37 AM Kees Cook wrote:
> > >
> > > This belongs over into patch 1.
> >
> > Thanks! I was rushing to get this posted so YiFei Zhu wouldn't spend
> > time fighting with arch and Kconfig stuff. :) I'll clean this (
On Thu, Sep 24, 2020 at 2:37 AM Kees Cook wrote:
> >
> > This belongs over into patch 1.
>
> Thanks! I was rushing to get this posted so YiFei Zhu wouldn't spend
> time fighting with arch and Kconfig stuff. :) I'll clean this (and the
> other random cruft) up.
Wait, what? I'm sorry. We have alrea
On Thu, Sep 24, 2020 at 2:38 AM Kees Cook wrote:
> > Would you mind educating me how this patch plan one handling MIPS? For
> > one kernel they seem to have up to three arch numbers per build,
> > AUDIT_ARCH_MIPS{,64,64N32}. Though ARCH_TRACE_IGNORE_COMPAT_SYSCALLS
> > does not seem to be defined
On Wed, Sep 23, 2020 at 07:36:47PM -0500, YiFei Zhu wrote:
> On Wed, Sep 23, 2020 at 6:29 PM Kees Cook wrote:
> > In order to optimize these cases from O(n) to O(1), seccomp can
> > use bitmaps to immediately determine the desired action. A critical
> > observation in the prior paragraph bears rep
On Thu, Sep 24, 2020 at 02:25:03AM +0200, Jann Horn wrote:
> On Thu, Sep 24, 2020 at 1:29 AM Kees Cook wrote:
> > +/* When no bits are set for a syscall, filters are run. */
> > +struct seccomp_bitmaps {
> > +#ifdef SECCOMP_ARCH
> > + /* "allow" are initialized to set and only ever get clear
On Wed, Sep 23, 2020 at 6:29 PM Kees Cook wrote:
> In order to optimize these cases from O(n) to O(1), seccomp can
> use bitmaps to immediately determine the desired action. A critical
> observation in the prior paragraph bears repeating: the common case for
> syscall tests do not check arguments.
On Thu, Sep 24, 2020 at 1:29 AM Kees Cook wrote:
> One of the most common pain points with seccomp filters has been dealing
> with the overhead of processing the filters, especially for "always allow"
> or "always reject" cases.
The "always reject" cases don't need to be fast, in particular not t
11 matches
Mail list logo
