rfc:
https://lore.kernel.org/lkml/20200616074934.1600036-1-keesc...@chromium.org/
alternative:
https://lore.kernel.org/containers/cover.1600661418.git.yifei...@illinois.edu/
v1:
- rebase to for-next/seccomp
- finish X86_X32 support for both pinning and bitmaps
- replace TLB magic with Jann's emul
On Sat, Sep 26, 2020 at 01:11:50PM -0500, YiFei Zhu wrote:
> On Fri, Sep 25, 2020 at 2:07 AM YiFei Zhu wrote:
> > I'll try to profile the latter later on my qemu-kvm, with a recent
> > libsecomp with binary tree and docker's profile, probably both direct
> > filter attaches and filter attaches wit
On Mon, Sep 28, 2020 at 3:04 PM Kees Cook wrote:
> Regardless, let's take things one step at a time. First, let's do
> the simplest version of the feature, and then let's look at further
> optimizations.
>
> Can you send a v3 and we can continue from there?
ok, will do later tonight / tomorrow.
On 24/09/2020 01.29, Kees Cook wrote:
> rfc:
> https://lore.kernel.org/lkml/20200616074934.1600036-1-keesc...@chromium.org/
> alternative:
> https://lore.kernel.org/containers/cover.1600661418.git.yifei...@illinois.edu/
> v1:
> - rebase to for-next/seccomp
> - finish X86_X32 support for both pinn
On Thu, Sep 24, 2020 at 8:46 AM Rasmus Villemoes
wrote:
> But one thing I'm wondering about and I haven't seen addressed anywhere:
> Why build the bitmap on the kernel side (with all the complexity of
> having to emulate the filter for all syscalls)? Why can't userspace just
> hand the kernel "her
On Thu, Sep 24, 2020 at 3:40 PM Rasmus Villemoes
wrote:
> On 24/09/2020 01.29, Kees Cook wrote:
> > rfc:
> > https://lore.kernel.org/lkml/20200616074934.1600036-1-keesc...@chromium.org/
> > alternative:
> > https://lore.kernel.org/containers/cover.1600661418.git.yifei...@illinois.edu/
> > v1:
>
Hello,
I'm posting this only for the record, feel free to ignore.
On Wed, Sep 23, 2020 at 04:29:17PM -0700, Kees Cook wrote:
> rfc:
> https://lore.kernel.org/lkml/20200616074934.1600036-1-keesc...@chromium.org/
> alternative:
> https://lore.kernel.org/containers/cover.1600661418.git.yifei...@il
On Thu, Sep 24, 2020 at 8:57 PM Andrea Arcangeli wrote:
>
> Hello,
>
> I'm posting this only for the record, feel free to ignore.
>
> On Wed, Sep 23, 2020 at 04:29:17PM -0700, Kees Cook wrote:
> > rfc:
> > https://lore.kernel.org/lkml/20200616074934.1600036-1-keesc...@chromium.org/
> > alternativ
On Thu, Sep 24, 2020 at 2:19 PM Jann Horn wrote:
>
> On Thu, Sep 24, 2020 at 8:57 PM Andrea Arcangeli wrote:
> >
> > Hello,
> >
> > I'm posting this only for the record, feel free to ignore.
> >
> > On Wed, Sep 23, 2020 at 04:29:17PM -0700, Kees Cook wrote:
> > > rfc:
> > > https://lore.kernel.o
On Thu, Sep 24, 2020 at 02:57:02PM -0400, Andrea Arcangeli wrote:
> Hello,
>
> I'm posting this only for the record, feel free to ignore.
>
> On Wed, Sep 23, 2020 at 04:29:17PM -0700, Kees Cook wrote:
> > rfc:
> > https://lore.kernel.org/lkml/20200616074934.1600036-1-keesc...@chromium.org/
> > a
On 24/09/2020 15.58, YiFei Zhu wrote:
> On Thu, Sep 24, 2020 at 8:46 AM Rasmus Villemoes
> wrote:
>> But one thing I'm wondering about and I haven't seen addressed anywhere:
>> Why build the bitmap on the kernel side (with all the complexity of
>> having to emulate the filter for all syscalls)? Wh
On Fri, Sep 25, 2020 at 12:56 AM Rasmus Villemoes
wrote:
> Yes, the man page would read something like
>
>SECCOMP_SET_MODE_FILTER_BITMAP
> The system calls allowed are defined by a pointer to a
> Berkeley Packet Filter (BPF) passed via args.
> This argument is
On Fri, Sep 25, 2020 at 2:07 AM YiFei Zhu wrote:
> I'll try to profile the latter later on my qemu-kvm, with a recent
> libsecomp with binary tree and docker's profile, probably both direct
> filter attaches and filter attaches with fork(). I'm guessing if I
> have fork() the cost of fork() will o
13 matches
Mail list logo
