On Fri, Sep 25, 2020 at 07:47:47PM -0700, Andy Lutomirski wrote:
>
> > On Sep 25, 2020, at 6:23 PM, YiFei Zhu wrote:
> >
> > On Fri, Sep 25, 2020 at 4:07 PM Andy Lutomirski
> > wrote:
> >> We'd need at least three states per syscall: unknown, always-allow,
> >> and need-to-run-filter.
> >>
> On Sep 25, 2020, at 6:23 PM, YiFei Zhu wrote:
>
> On Fri, Sep 25, 2020 at 4:07 PM Andy Lutomirski wrote:
>> We'd need at least three states per syscall: unknown, always-allow,
>> and need-to-run-filter.
>>
>> The downsides are less determinism and a bit of an uglier
>> implementation.
On Fri, Sep 25, 2020 at 4:07 PM Andy Lutomirski wrote:
> We'd need at least three states per syscall: unknown, always-allow,
> and need-to-run-filter.
>
> The downsides are less determinism and a bit of an uglier
> implementation. The upside is that we don't need to loop over all
> syscalls at
> On Sep 25, 2020, at 4:49 PM, Kees Cook wrote:
>
> On Fri, Sep 25, 2020 at 02:07:46PM -0700, Andy Lutomirski wrote:
>>> On Fri, Sep 25, 2020 at 1:37 PM Kees Cook wrote:
>>>
>>> On Fri, Sep 25, 2020 at 12:51:20PM -0700, Andy Lutomirski wrote:
> On Sep 25, 2020, at 12:42 PM,
On Fri, Sep 25, 2020 at 02:07:46PM -0700, Andy Lutomirski wrote:
> On Fri, Sep 25, 2020 at 1:37 PM Kees Cook wrote:
> >
> > On Fri, Sep 25, 2020 at 12:51:20PM -0700, Andy Lutomirski wrote:
> > >
> > >
> > > > On Sep 25, 2020, at 12:42 PM, Kees Cook wrote:
> > > >
> > > > On Fri, Sep 25, 2020 at
On Fri, Sep 25, 2020 at 1:37 PM Kees Cook wrote:
>
> On Fri, Sep 25, 2020 at 12:51:20PM -0700, Andy Lutomirski wrote:
> >
> >
> > > On Sep 25, 2020, at 12:42 PM, Kees Cook wrote:
> > >
> > > On Fri, Sep 25, 2020 at 11:45:05AM -0500, YiFei Zhu wrote:
> > >> On Thu, Sep 24, 2020 at 10:04 PM YiFei
On Fri, Sep 25, 2020 at 12:51:20PM -0700, Andy Lutomirski wrote:
>
>
> > On Sep 25, 2020, at 12:42 PM, Kees Cook wrote:
> >
> > On Fri, Sep 25, 2020 at 11:45:05AM -0500, YiFei Zhu wrote:
> >> On Thu, Sep 24, 2020 at 10:04 PM YiFei Zhu wrote:
> Why do the prepare here instead of during
On Fri, Sep 25, 2020 at 11:45:05AM -0500, YiFei Zhu wrote:
> On Thu, Sep 24, 2020 at 10:04 PM YiFei Zhu wrote:
> > > Why do the prepare here instead of during attach? (And note that it
> > > should not be written to fail.)
> >
> > Right.
>
> During attach a spinlock (current->sighand->siglock)
> On Sep 25, 2020, at 12:42 PM, Kees Cook wrote:
>
> On Fri, Sep 25, 2020 at 11:45:05AM -0500, YiFei Zhu wrote:
>> On Thu, Sep 24, 2020 at 10:04 PM YiFei Zhu wrote:
Why do the prepare here instead of during attach? (And note that it
should not be written to fail.)
>>>
>>> Right.
On Thu, Sep 24, 2020 at 10:04 PM YiFei Zhu wrote:
> > Why do the prepare here instead of during attach? (And note that it
> > should not be written to fail.)
>
> Right.
During attach a spinlock (current->sighand->siglock) is held. Do we
really want to put the emulator in the "atomic section"?
[resending this, forgot to hit reply all...]
On Thu, Sep 24, 2020 at 6:25 PM Kees Cook wrote:
> I'm not interested in seccomp having a config option for this. It should
> entire exist or not, and that depends on the per-architecture support.
> You mentioned in another thread that you wanted it
On Thu, Sep 24, 2020 at 07:44:18AM -0500, YiFei Zhu wrote:
> From: YiFei Zhu
>
> SECCOMP_CACHE_NR_ONLY will only operate on syscalls that do not
> access any syscall arguments or instruction pointer. To facilitate
> this we need a static analyser to know whether a filter will
> return allow
From: YiFei Zhu
SECCOMP_CACHE_NR_ONLY will only operate on syscalls that do not
access any syscall arguments or instruction pointer. To facilitate
this we need a static analyser to know whether a filter will
return allow regardless of syscall arguments for a given
architecture number / syscall
13 matches
Mail list logo
