RCH_NATIVE_NAME"m68k"
If the file does not exist already, arch/xtensa/include/asm/seccomp.h
is a good example of how the file should look like, and remember to
remove `generic-y += seccomp.h` from arch/m68k/include/asm/Kbuild.
[1] https://lore.kernel.org/lkml/cover.1605101222.git.yifei...@illinois.edu/T/
YiFei Zhu
From: YiFei Zhu
This patch series enables bitmap cache for the remaining arches with
SECCOMP_FILTER, other than MIPS.
I was unable to find any of the arches having subarch-specific NR_syscalls
macros, so generic NR_syscalls is used. SH's syscall_get_arch seems to
only have the 32-bit subarch
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for xtensa.
Signed-off-by: YiFei Zhu
---
arch/xtensa/include/asm/Kbuild| 1 -
arch/xtensa/include/asm/seccomp.h | 11 +++
2
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for sh.
Signed-off-by: YiFei Zhu
---
arch/sh/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for s390.
Signed-off-by: YiFei Zhu
---
arch/s390/include/asm/seccomp.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for riscv.
Signed-off-by: YiFei Zhu
---
arch/riscv/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for parisc.
Signed-off-by: YiFei Zhu
---
arch/parisc/include/asm/Kbuild| 1 -
arch/parisc/include/asm/seccomp.h | 22
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for powerpc.
__LITTLE_ENDIAN__ is used here instead of CONFIG_CPU_LITTLE_ENDIAN
to keep it consistent with asm/syscall.h.
Signed-off
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for csky.
Signed-off-by: YiFei Zhu
---
arch/csky/include/asm/Kbuild| 1 -
arch/csky/include/asm/seccomp.h | 11 +++
2 files
dian and "ppc64le" for 64-bit
> little endian.
>
> And usually we use "ppc" for 32-bit.
Ok.
YiFei Zhu
2_user=prctl" on the
command line and test the performance of that?
YiFei Zhu
From: YiFei Zhu
This patch series enables bitmap cache for the remaining arches with
SECCOMP_FILTER, other than MIPS.
I was unable to find any of the arches having subarch-specific NR_syscalls
macros, so generic NR_syscalls is used. SH's syscall_get_arch seems to
only have the 32-bit subarch
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for s390.
Signed-off-by: YiFei Zhu
---
arch/s390/include/asm/seccomp.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for riscv.
Signed-off-by: YiFei Zhu
---
arch/riscv/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for parisc.
Signed-off-by: YiFei Zhu
---
arch/parisc/include/asm/Kbuild| 1 -
arch/parisc/include/asm/seccomp.h | 22
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for powerpc.
Signed-off-by: YiFei Zhu
---
arch/powerpc/include/asm/seccomp.h | 21 +
1 file changed, 21 insertions
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for csky.
Signed-off-by: YiFei Zhu
---
arch/csky/include/asm/Kbuild| 1 -
arch/csky/include/asm/seccomp.h | 11 +++
2 files
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for xtensa.
Signed-off-by: YiFei Zhu
---
arch/xtensa/include/asm/Kbuild| 1 -
arch/xtensa/include/asm/seccomp.h | 11 +++
2
From: YiFei Zhu
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for sh.
Signed-off-by: YiFei Zhu
---
arch/sh/include/asm/seccomp.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch
On Fri, Oct 30, 2020 at 7:18 AM YiFei Zhu wrote:
> I got a bare metal test machine with Intel(R) Xeon(R) CPU E5-2660 v3 @
> 2.60GHz, running Ubuntu 18.04. Test kernels are compiled at
> 57a339117e52 ("selftests/seccomp: Compare bitmap vs filter overhead")
> and 3650b22
.77system 18:49.09elapsed 98%CPU (0avgtext+0avgdata
239684maxresident)k
0inputs+217152outputs (0major+51549745minor)pagefaults 0swaps
YiFei Zhu
tectures, so you
are probably right that those that did not have it on by default
should be kept off by default; many of them could be for embedded
devices. What's the best way to do this? Set it as default N in
Kconfig and add CONFIG_SECCOMP=y in each arch's defconfig?
YiFei Zhu
isy and CPU isolation
> continues to frustrate me. :)
Ok, let me know if I can help.
YiFei Zhu
On Mon, Oct 12, 2020 at 7:31 PM YiFei Zhu wrote:
>
> On Mon, Oct 12, 2020 at 5:57 PM Kees Cook wrote:
> > I think it's fine to just have this "dangle" with a help text update of
> > "if seccomp action caching is supported by the architecture, provide the
> &g
text and wonder...
"hmm does my architecture support seccomp action caching" and without
a clear pointer to how seccomp action cache works, goes and compiles
the kernel with this config option on for the purpose of knowing if
their arch supports it... Or, is it a common practice in the k
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
bitmapped (29 ≈ 29): ✔️
entry ≈ 2 bitmapped (29 ≈ 29): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (755 ≈ 752): ✔️
Signed-off-by: Kees Cook
[YiFei: Changed commit message to show stats for this patch series]
Signed-off-by: YiFei Zhu
---
.../selftests/seccomp
From: Kees Cook
Provide seccomp internals with the details to calculate which syscall
table the running kernel is expecting to deal with. This allows for
efficient architecture pinning and paves the way for constant-action
bitmaps.
Signed-off-by: Kees Cook
Co-developed-by: YiFei Zhu
Signed
From: YiFei Zhu
SECCOMP_CACHE 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 number
From: YiFei Zhu
The overhead of running Seccomp filters has been part of some past
discussions [1][2][3]. Oftentimes, the filters have a large number
of instructions that check syscall numbers one by one and jump based
on that. Some users chain BPF filters which further enlarge the
overhead
From: YiFei Zhu
Alternative:
https://lore.kernel.org/lkml/20200923232923.3142503-1-keesc...@chromium.org/T/
Major differences from the linked alternative by Kees:
* No x32 special-case handling -- not worth the complexity
* No caching of denylist -- not worth the complexity
* No seccomp arch
On Fri, Oct 9, 2020 at 6:14 PM Kees Cook wrote:
> HAVE_ARCH_SECCOMP_CACHE isn't used any more. I think this was left over
> from before.
Oh, I was meant to add this to the dependencies of
SECCOMP_CACHE_DEBUG. Is this something that would make sense?
YiFei Zhu
re do
you think I should put a comment? seccomp_cache_check_allow_bitmap
above `if (unlikely(syscall_nr < 0 || syscall_nr >= bitmap_size))`,
with something like "any syscall number out of range is unoptimized"?
YiFei Zhu
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
From: Kees Cook
Provide seccomp internals with the details to calculate which syscall
table the running kernel is expecting to deal with. This allows for
efficient architecture pinning and paves the way for constant-action
bitmaps.
Signed-off-by: Kees Cook
Co-developed-by: YiFei Zhu
Signed
bitmapped (29 ≈ 29): ✔️
entry ≈ 2 bitmapped (29 ≈ 29): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (755 ≈ 752): ✔️
Signed-off-by: Kees Cook
[YiFei: Changed commit message to show stats for this patch series]
Signed-off-by: YiFei Zhu
---
.../selftests/seccomp
From: YiFei Zhu
The overhead of running Seccomp filters has been part of some past
discussions [1][2][3]. Oftentimes, the filters have a large number
of instructions that check syscall numbers one by one and jump based
on that. Some users chain BPF filters which further enlarge the
overhead
From: YiFei Zhu
SECCOMP_CACHE 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 number
From: YiFei Zhu
Alternative:
https://lore.kernel.org/lkml/20200923232923.3142503-1-keesc...@chromium.org/T/
Major differences from the linked alternative by Kees:
* No x32 special-case handling -- not worth the complexity
* No caching of denylist -- not worth the complexity
* No seccomp arch
On Wed, Sep 30, 2020 at 10:20 AM YiFei Zhu wrote:
> @@ -544,7 +577,8 @@ static struct seccomp_filter
> *seccomp_prepare_filter(struct sock_fprog *fprog)
> {
> struct seccomp_filter *sfilter;
> int ret;
> - const bool save_orig = IS_ENABLED(CONFIG_
On Wed, Sep 30, 2020 at 4:32 PM Kees Cook wrote:
>
> On Wed, Sep 30, 2020 at 10:19:14AM -0500, YiFei Zhu wrote:
> > From: YiFei Zhu
> >
> > The fast (common) path for seccomp should be that the filter permits
> > the syscall to pass through, a
uot;evaluate"
> step, so I'd like the code designed to make things MORE restrictive not
> less from the start, and remove any prior cache state tests from the
> loop.
>
> At the end of the day I believe changing the design like this now lays
> the groundwork to the caching mechanism being more robust against having
> future bugs introduce security flaws.
>
I see. Makes sense. Thanks. Will do that in the v4
YiFei Zhu
ot; are kept alive by the reference to
> it.
Ah I see. Thanks for the explanation.
> By the way, maybe it'd make sense to add this to tid_base_stuff as
> well? That should just be one extra line of code. Seccomp filters are
> technically per-thread, so it would make sense to have them visible in
> the per-thread subdirectories /proc/$pid/task/$tid/.
Right. Will do.
YiFei Zhu
t
will, at the end, decrease the reference count of the task_struct.
Does procfs increase the refcount while calling the procfs functions?
Hence, in procfs functions one can rely on the task_struct still being
a task_struct, but any direct effects of release_task may happen while
the procfs functions are running?
YiFei Zhu
_is_const_allow(fprog, ))
> continue;
>
> /* Not a cacheable action: always run filters. */
> clear_bit(nr, bitmap);
I'm not strongly against this logic. I just feel unconvinced that this
is any different with a slightly increased complexity.
YiFei Zhu
primed, then I undid that.
> > + set_bit(nr, bitmap);
>
> set_bit() is atomic, but since we only do this at filter setup, before
> the filter becomes globally visible, we don't need atomicity here. So
> this should probably use __set_bit() instead.
Right
YiFei Zhu
From: YiFei Zhu
Alternative:
https://lore.kernel.org/lkml/20200923232923.3142503-1-keesc...@chromium.org/T/
Major differences from the linked alternative by Kees:
* No x32 special-case handling -- not worth the complexity
* No caching of denylist -- not worth the complexity
* No seccomp arch
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
bitmapped (29 ≈ 29): ✔️
entry ≈ 2 bitmapped (29 ≈ 29): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (755 ≈ 752): ✔️
Signed-off-by: Kees Cook
[YiFei: Changed commit message to show stats for this patch series]
Signed-off-by: YiFei Zhu
---
.../selftests/seccomp
From: YiFei Zhu
The fast (common) path for seccomp should be that the filter permits
the syscall to pass through, and failing seccomp is expected to be
an exceptional case; it is not expected for userspace to call a
denylisted syscall over and over.
This first finds the current allow bitmask
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
for nr_syscalls]
Signed-off-by: YiFei Zhu
---
arch/x86/include/asm/seccomp.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/include/asm/seccomp.h b/arch/x86/include/asm/seccomp.h
index 2bd1338de236..7b3a58271656 100644
--- a/arch/x86/include/asm/seccomp.h
+++ b/arch/x86
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 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
ways
allow" is cleared but not "known" bit then we have an issue: the
syscall will always be executed in BPF.
Is it worth holding a spinlock here?
Though I'll try to get the benchmark numbers for the emulator later tonight.
YiFei Zhu
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 emulato
On Thu, Sep 24, 2020 at 10:28 PM YiFei Zhu wrote:
> Ah. Makes sense.
>
> > Ironicailly, that's the only place I actually know for sure where people
> > using x32 because it shows measurable (10%) speed-up for builders:
> > https://lore.kernel.org/lkml/caoesgmgu1i3p
p 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 overshadow seccomp() though.
[1]
https://lore.kernel.org/containers/cover.1600661418.git.yifei...@illinois.edu/
[2] https://github.com/seccomp/libseccomp/pull/152
YiFei Zhu
o check the given seccomp_data belongs to the arch and if
so, the order of the bit in the bitmap. There is no need for the
shifts and madness in seccomp.c; it's arch-dependent code in their own
seccomp.h. We let the preprocessor and compiler to make things
optimized.
YiFei Zhu
. (Though, as devil's advocate again, to repeat
> Jann's own words back: do we want to add this only to have a new UAPI to
> support going forward?)
Is this something we want to keep stable?
YiFei Zhu
: we can only remove bits from syscall_ok, never add them.
> sfilter must be constructed so that it can only ever have fewer or the
> same bits set as prev.
Right.
> In the RFC I did this inherit earlier (in the emulation stage) to
> benefit from the RET_KILL results, but that's not very useful any more.
> However, I think it's still code-locality better to keep the bit
> manipulation logic as close together as possible for readability.
Right.
[1] http://www.catb.org/esr/structure-packing/#_structure_alignment_and_padding
YiFei Zhu
stant.
Also, does "collapse in one arch case" actually worth it? Given that
there's a likely(), and the other side is a WARN_ON_ONCE(), the
compiler will layout the likely path in the fast path and branch
prediction will be in our favor, right?
YiFei Zhu
Or if you mean if I expected these results, yes.
YiFei Zhu
[resending this too]
On Thu, Sep 24, 2020 at 6:01 PM Kees Cook wrote:
> Disregarding the "how" of this, yeah, we'll certainly need something to
> tell seccomp about the arrangement of syscall tables and how to find
> them.
>
> However, I'd still prefer to do this on a per-arch basis, and include
On Thu, Sep 24, 2020 at 9:37 AM YiFei Zhu wrote:
> > Try with a slghtly older gcc.
> > I think that entire optimisation (discarding const arrays)
> > is very recent.
>
> Will try, will take a while to get an old GCC to run, however :/
Possibly one of the oldest I can e
> is very recent.
Will try, will take a while to get an old GCC to run, however :/
YiFei Zhu
FOR_PERFORMANCE rather than
CC_OPTIMIZE_FOR_SIZE, but this patch itself is trying to sacrifice
some of the memory for speed.
YiFei Zhu
esign?
> I'm also a bit worried about the performance of doing that emulation;
> that's constant extra overhead for, say, launching a docker container.
IMO, launching a docker container is so expensive this should be negligible.
YiFei Zhu
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
≈ 26): ✔️
entry ≈ 2 bitmapped (26 ≈ 26): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (732 ≈ 737): ✔️
Signed-off-by: Kees Cook
Signed-off-by: YiFei Zhu
---
.../selftests/seccomp/seccomp_benchmark.c | 151 +++---
tools/testing/selftests/seccomp/settings
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
From: YiFei Zhu
The fast (common) path for seccomp should be that the filter permits
the syscall to pass through, and failing seccomp is expected to be
an exceptional case; it is not expected for userspace to call a
denylisted syscall over and over.
This first finds the current allow bitmask
From: YiFei Zhu
Seccomp cache emulator needs to know all the architecture numbers
that syscall_get_arch() could return for the kernel build in order
to generate a cache for all of them.
The array is declared in header as static __maybe_unused const
to maximize compiler optimiation opportunities
From: YiFei Zhu
Alternative:
https://lore.kernel.org/lkml/20200923232923.3142503-1-keesc...@chromium.org/T/
Major differences from the linked alternative by Kees:
* No x32 special-case handling -- not worth the complexity
* No caching of denylist -- not worth the complexity
* No seccomp arch
From: YiFei Zhu
In order to make adding configurable features into seccomp
easier, it's better to have the options at one single location,
considering easpecially that the bulk of seccomp code is
arch-independent. An quick look also show that many SECCOMP
descriptions are outdated; they talk
From: YiFei Zhu
Seccomp cache emulator needs to know all the architecture numbers
that syscall_get_arch() could return for the kernel build in order
to generate a cache for all of them.
The array is declared in header as static __maybe_unused const
to maximize compiler optimiation opportunities
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
From: YiFei Zhu
Alternative:
https://lore.kernel.org/lkml/20200923232923.3142503-1-keesc...@chromium.org/T/
Major differences from the linked alternative by Kees:
* No x32 special-case handling -- not worth the complexity
* No caching of denylist -- not worth the complexity
* No seccomp arch
≈ 26): ✔️
entry ≈ 2 bitmapped (26 ≈ 26): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (732 ≈ 737): ✔️
Signed-off-by: Kees Cook
Signed-off-by: YiFei Zhu
---
.../selftests/seccomp/seccomp_benchmark.c | 151 +++---
tools/testing/selftests/seccomp/settings
From: YiFei Zhu
The fast (common) path for seccomp should be that the filter permits
the syscall to pass through, and failing seccomp is expected to be
an exceptional case; it is not expected for userspace to call a
denylisted syscall over and over.
This first finds the current allow bitmask
From: YiFei Zhu
Currently the kernel does not provide an infrastructure to translate
architecture numbers to a human-readable name. Translating syscall
numbers to syscall names is possible through FTRACE_SYSCALL
infrastructure but it does not provide support for compat syscalls
From: YiFei Zhu
In order to make adding configurable features into seccomp
easier, it's better to have the options at one single location,
considering easpecially that the bulk of seccomp code is
arch-independent. An quick look also show that many SECCOMP
descriptions are outdated; they talk
ir, then it is "cached by bitmap".
> I'm open to ideas, but I want to have a non-optional performance
> improvement as the first step. :)
How about "performance improvement by default"? It's not like most end
users / distros would turn off something that's enabled by d
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,
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
does not seem to be defined for MIPS so I'm assuming the syscall
numbers are the same, but I think it is possible some client uses that
arch number to pose different constraints for different processes, so
it would better not accelerate them rather than break them.
YiFei Zhu
ates why
> putting such options into arch-specific Kconfig is a bad idea. :P
Ah, time to fix this then.
YiFei Zhu
SECCOMP
in the arch-specific Kconfigs?
> I think we should probably just bail out if we see anything that's
> BPF_ST/BPF_STX. I've never seen seccomp filters that actually use that
> part of cBPF.
>
> But in case we do need this, maybe instead of using "2 +" for all
> these things, the cBPF memory slots should be in a separate array.
Ok I'll just bail.
YiFei Zhu
ry, that was a bit unclear.
I see, building an immutable accept bitmask when preparing and then
just use that when running it. I guess if the arch number issue is
resolved this should be more doable. Will do.
YiFei Zhu
t the differences" in the unlikely case that some issue
occurs. Jann pointed that it should be on by default so I'll do that.
YiFei Zhu
On Mon, Sep 21, 2020 at 1:09 PM Jann Horn wrote:
>
> On Mon, Sep 21, 2020 at 7:35 AM YiFei Zhu wrote:
> [...]
> > We do this by creating a per-task bitmap of permitted syscalls.
> > If seccomp filter is invoked we check if it is cached and if so
> > directly
additional flag for
does-userspace-want-us-to-cache, it would still be a member of the
filter struct. What would be loaded into the CPU data cache originally
would still be loaded. Correct me if I'm wrong, but I don't think that
check will reduce any significant overhead of the seccomp cache
itself.
That s
On Mon, Sep 21, 2020 at 3:30 AM Christian Brauner
wrote:
> This is missing some people so expanding the Cc a little. Make sure to
> run scripts/get_maintainers.pl next time, in case you forgot. (Adding
> Andy, Will, Jann, Aleksa at least.)
>
> Christian
ok noted. Thanks!
YiFei Zhu
Commit-ID: 79c2206d369b87b19ac29cb47601059b6bf5c291
Gitweb: https://git.kernel.org/tip/79c2206d369b87b19ac29cb47601059b6bf5c291
Author: YiFei Zhu
AuthorDate: Thu, 29 Nov 2018 18:12:30 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Nov 2018 09:05:13 +0100
x86/earlyprintk/efi: Fix
Commit-ID: 79c2206d369b87b19ac29cb47601059b6bf5c291
Gitweb: https://git.kernel.org/tip/79c2206d369b87b19ac29cb47601059b6bf5c291
Author: YiFei Zhu
AuthorDate: Thu, 29 Nov 2018 18:12:30 +0100
Committer: Ingo Molnar
CommitDate: Fri, 30 Nov 2018 09:05:13 +0100
x86/earlyprintk/efi: Fix
97 matches
Mail list logo
