On Tue, Feb 20, 2018 at 09:13:28PM +0100, Eugene Syromiatnikov wrote:
> On Tue, Nov 14, 2017 at 07:00:19PM -0700, Tycho Andersen wrote:
> > With the new SECCOMP_FILTER_FLAG_LOG, we need to be able to extract these
> > flags for checkpoint restore, since they describe the state of a filter.
> >
> >
On Tue, Feb 20, 2018 at 10:30:52PM +0300, Dmitry V. Levin wrote:
> > +struct seccomp_metadata {
> > + unsigned long filter_off; /* Input: which filter */
> > + unsigned int flags; /* Output: filter's flags */
> > +};
>
> This "unsigned long" field is unacceptable unless you a
On Tue, Nov 14, 2017 at 07:00:19PM -0700, Tycho Andersen wrote:
> With the new SECCOMP_FILTER_FLAG_LOG, we need to be able to extract these
> flags for checkpoint restore, since they describe the state of a filter.
>
> So, let's add PTRACE_SECCOMP_GET_METADATA, similar to ..._GET_FILTER, which
> r
Hi,
On Tue, Nov 14, 2017 at 07:00:19PM -0700, Tycho Andersen wrote:
> With the new SECCOMP_FILTER_FLAG_LOG, we need to be able to extract these
> flags for checkpoint restore, since they describe the state of a filter.
>
> So, let's add PTRACE_SECCOMP_GET_METADATA, similar to ..._GET_FILTER, whic
With the new SECCOMP_FILTER_FLAG_LOG, we need to be able to extract these
flags for checkpoint restore, since they describe the state of a filter.
So, let's add PTRACE_SECCOMP_GET_METADATA, similar to ..._GET_FILTER, which
returns the metadata of the nth filter (right now, just the flags).
Hopeful
5 matches
Mail list logo
