architecture check as the first filter
action.
This creates the internal representation that seccomp itself can use
(which is separate from the filters, which need to stay runtime
agnostic). Additionally paves the way for constant-action bitmaps.
Signed-off-by: Kees Cook
---
include/linux/seccomp.h
omes
in the next patch.)
[1]
https://lore.kernel.org/bpf/20200531171915.wsxvdjeetmhps...@ast-mbp.dhcp.thefacebook.com/
[2] https://lore.kernel.org/bpf/20200601101137.GA121847@gardel-login/
[3] https://lore.kernel.org/bpf/717a06e7f35740ccb4c70470ec70f...@huawei.com/
Thanks!
-Kees
≈ 2 bitmapped (20 ≈ 22): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (844 ≈ 844): ✔️
Signed-off-by: Kees Cook
---
.../selftests/seccomp/seccomp_benchmark.c | 151 +++---
tools/testing/selftests/seccomp/settings | 2 +-
2 files changed, 130 insertions(+), 23
This is what I've been using to explore actual bitmap results for
real-world filters...
Signed-off-by: Kees Cook
---
kernel/seccomp.c | 115 +++
1 file changed, 115 insertions(+)
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 9921f6f
On Wed, Sep 23, 2020 at 03:19:08PM -0600, Shuah Khan wrote:
> On 9/23/20 2:58 PM, Kees Cook wrote:
> > On Wed, Sep 23, 2020 at 02:48:22PM -0600, Shuah Khan wrote:
> > > On 9/23/20 1:04 PM, Kees Cook wrote:
> > > > On Tue, Sep 22, 2020 at 07:43:30PM -0600, Shuah Khan
On Wed, Sep 23, 2020 at 08:43:21PM +0200, Ard Biesheuvel wrote:
> On Wed, 23 Sep 2020 at 20:41, Kees Cook wrote:
> >
> > On Wed, Sep 23, 2020 at 06:13:58PM +0200, Ard Biesheuvel wrote:
> > > The EFI pstore implementation relies on the 'efivars' abstraction
On Wed, Sep 23, 2020 at 02:48:22PM -0600, Shuah Khan wrote:
> On 9/23/20 1:04 PM, Kees Cook wrote:
> > On Tue, Sep 22, 2020 at 07:43:30PM -0600, Shuah Khan wrote:
> > I would really like these APIs to be _impossible_ to use for object
> > lifetime management. To that end, I w
On Wed, Sep 23, 2020 at 09:34:48PM +0200, Greg KH wrote:
> On Wed, Sep 23, 2020 at 12:04:08PM -0700, Kees Cook wrote:
> > On Tue, Sep 22, 2020 at 07:43:30PM -0600, Shuah Khan wrote:
> > > Introduce Simple atomic and non-atomic counters.
> > >
> > > There ar
On Wed, Sep 23, 2020 at 09:31:34PM +0200, Greg KH wrote:
> On Wed, Sep 23, 2020 at 12:04:58PM -0700, Kees Cook wrote:
> > On Wed, Sep 23, 2020 at 07:10:27AM +0200, Greg KH wrote:
> > > On Tue, Sep 22, 2020 at 07:43:36PM -0600, Shuah Khan wrote:
> >
On Wed, Sep 23, 2020 at 04:18:26PM -0400, Gabriel Krisman Bertazi wrote:
> Kees Cook writes:
>
> > On Fri, Sep 04, 2020 at 04:31:39PM -0400, Gabriel Krisman Bertazi wrote:
> >> Convert TIF_SECCOMP into a generic TI flag for any syscall interception
> >> work being d
would expect this form to be much
robust:
inc
load sp from per-cpu
pivot sp
make call
restore sp
WARN(dec_and_test)
-Kees
[1]
https://security.stackexchange.com/questions/44418/return-oriented-programming-how-to-find-a-stack-pivot
--
Kees Cook
truct counter_atomic br[_IOC_NR(BR_FAILED_REPLY) + 1];
> > + struct counter_atomic bc[_IOC_NR(BC_REPLY_SG) + 1];
> > + struct counter_atomic obj_created[BINDER_STAT_COUNT];
> > + struct counter_atomic obj_deleted[BINDER_STAT_COUNT];
>
> These are just debugging statistics, no reason they have to be atomic
> variables at all and they should be able to just be "struct counter"
> variables instead.
But there's no reason for them _not_ to be atomic. Please let's keep
this API as always safe. Why even provide a new foot-gun here?
--
Kees Cook
al;
Please build this test using KUnit.
> + start_val = counter_long_read(&acnt);
> + end_val = counter_long_dec_return(&acnt);
> + pr_info("Test read decrement and return: %ld to %ld - %s\n",
> + start_val, end_val,
> + ((start_val-1 == end_val) ? "PASS" : "FAIL"));
I also see a lot of copy/paste patterns here. These should all use a
common helper.
--
Kees Cook
dule is deprecated, and all users appear to
> have moved to the efivarfs file system instead, let's prepare for
> its removal, by removing EFI pstore's dependency on it.
>
> Signed-off-by: Ard Biesheuvel
With this and the other pstore patch, do the pstore self-tests still
p
emantics of checking the
> syscall_intercept flag, like it is done in the common entry syscall
> code, or even better, migrate to the common syscall entry code.
Can we "eat" all the other flags like ptrace, audit, etc, too? Doing
this only for seccomp seems strange.
--
Kees Cook
> I was trying to reduce overhead to seccomp entry due to two cache misses
> when reading this structure. Measuring it seccomp_benchmark didn't show
> any difference with the unwrapped version, so perhaps it was a bit of
> premature optimization?
That should not be a thing to think about here. Structure randomization
already has a mode to protect against cache line issues. I would leave
this as just a new member; no wrapping struct.
--
Kees Cook
> Signed-off-by: Gabriel Krisman Bertazi
Look good to me; would anything else benefit from this information?
Reviewed-by: Kees Cook
--
Kees Cook
n Bertazi
Yup, this looks good; seccomp is glad to have a new SIGSYS friend. ;)
Acked-by: Kees Cook
--
Kees Cook
is sufficient to enable it. (Especially since there's a top
level config for SYSCALL_USER_DISPATCH, it feels like overkill).
--
Kees Cook
gt; - Update bad selector test to reflect change in API
>
> Changes since v3:
> - Sort entry in Makefile
> - Add SPDX header
> - Use __NR_syscalls if available
>
> Signed-off-by: Gabriel Krisman Bertazi
This passes, looks good. Thank you again for the self tests!
Acked-by: Kees Cook
--
Kees Cook
On Fri, Sep 04, 2020 at 04:31:47PM -0400, Gabriel Krisman Bertazi wrote:
> Explain the interface, provide some background and security notes.
>
> Signed-off-by: Gabriel Krisman Bertazi
Looks good to me!
Reviewed-by: Kees Cook
--
Kees Cook
The following commit has been merged into the x86/cleanups branch of tip:
Commit-ID: 900ffe39fec908e0aa26a30612e43ebc7140db79
Gitweb:
https://git.kernel.org/tip/900ffe39fec908e0aa26a30612e43ebc7140db79
Author:Kees Cook
AuthorDate:Sat, 19 Sep 2020 01:09:36 -07:00
Committer
Just to help myself and others with finding the correct function names,
fix a typo for "usermode" vs "user_mode".
Signed-off-by: Kees Cook
---
include/linux/entry-common.h | 2 +-
kernel/entry/common.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -
As the UAPI headers start to appear in distros, we need to avoid outdated
versions of struct clone_args to be able to test modern features;
rename to "struct __clone_args". Additionally update the struct size
macro names to match UAPI names.
Signed-off-by: Kees Cook
---
tools/testing
/20200911181012.171027-1-casca...@canonical.com/
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 40 +--
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp
/20200911181012.171027-1-casca...@canonical.com/
Fixes: 58d0a862f573 ("seccomp: add tests for ptrace hole")
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 25 ---
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/seccomp/sec
In preparation for setting syscall nr and ret values separately, refactor
the helpers to take a pointer to a value, so that a NULL can indicate
"do not change this respective value". This is done to keep the regset
read/write happening once and in one code path.
Signed-off-by:
syscall number/return handling for powerpc. Additionally
fixes clone3 (which seccomp depends on for testing) to run under MIPS
where an old struct clone_args has become visible.
(FWIW, I expect to take these via the seccomp tree.)
Thanks,
Kees Cook (4):
selftests/seccomp: Record syscall during ptrace
On Tue, Sep 15, 2020 at 06:25:28PM +0200, Christian Brauner wrote:
> On Sat, Sep 12, 2020 at 04:08:19AM -0700, Kees Cook wrote:
> > As the UAPI headers start to appear in distros, we need to avoid
> > outdated versions of struct clone_args to be able to test modern
> > featur
On Tue, Sep 15, 2020 at 05:55:46PM +0200, Christian Brauner wrote:
> On Sat, Sep 12, 2020 at 04:08:08AM -0700, Kees Cook wrote:
> > Remove the mips special-case in change_syscall().
> >
> > Signed-off-by: Kees Cook
> > ---
> > tools/testing/sel
On Fri, Sep 18, 2020 at 06:02:16PM +0200, John Wood wrote:
> On Thu, Sep 10, 2020 at 04:56:19PM -0700, Kees Cook wrote:
> > On Thu, Sep 10, 2020 at 01:21:07PM -0700, Kees Cook wrote:
> > > + pr_warn("fbfam: Offending process with PID %d killed\n",
&g
jobserver-exec to limit the number of jobs spawned.
>
> Signed-off-by: Sami Tolvanen
Thanks for the update; using jobserver-exec looks much better for
controlling the build resources. :)
Reviewed-by: Kees Cook
--
Kees Cook
the arguments can be reused in Makefile.modfinal.
>
> Signed-off-by: Sami Tolvanen
Thanks for reorganizing this!
Reviewed-by: Kees Cook
--
Kees Cook
I have is that I don't like the coverage of some
mitigation or detection to "silently" vary between builds. e.g. someone
would build with/without UBSAN_TRAP and end up with unexpectedly
different coverage. I'd rather there be a separate CONFIG that appears.
--
Kees Cook
I'm fine to turn that off.
--
Kees Cook
ot;TAP version 13" test.log
> 2
Oh thank you for tracking this down! I thought seccomp wasn't killing a
child or something, and hadn't found it yet. :)
Acked-by: Kees Cook
--
Kees Cook
/kselftest_harness.h | 5 +
> > > > 1 file changed, 5 insertions(+)
> > >
> > > Tested-by: Max Filippov
> > >
> >
> > Thank you both. Applying to linux-kselftest fixes for 5.9-rc7
> >
>
> Kees,
>
> I haven't pulled this in yet. If you want to take this through seccomp
> tree for dependencies:
>
> Acked-by: Shuah Khan
You can have it -- it's a global fix and more than the seccomp selftest
is likely affected. :)
--
Kees Cook
On Thu, Sep 17, 2020 at 08:40:06PM +0200, John Wood wrote:
> Hi,
>
> On Thu, Sep 10, 2020 at 04:18:08PM -0700, Kees Cook wrote:
> > On Thu, Sep 10, 2020 at 01:21:02PM -0700, Kees Cook wrote:
> > > From: John Wood
> > >
> > > Add a menu entry under &q
CLANG
> +CFLAGS_UBSAN += $(call cc-option, -fsanitize=array-bounds)
This would mean losing the local-bounds coverage? Isn't that for locally
defined arrays on the stack?
> + else
> +CFLAGS_UBSAN += $(call cc-option, -fsanitize=bounds)
> + endif
> endif
>
> ifdef CONFIG_UBSAN_MISC
> --
> 2.28.0.618.gf4bc123cb7-goog
>
--
Kees Cook
The following commit has been merged into the core/urgent branch of tip:
Commit-ID: b6ec413461034d49f9e586845825adb35ba308f6
Gitweb:
https://git.kernel.org/tip/b6ec413461034d49f9e586845825adb35ba308f6
Author:Kees Cook
AuthorDate:Fri, 11 Sep 2020 17:58:26 -07:00
Committer
On Mon, Sep 14, 2020 at 10:15:18PM +1000, Michael Ellerman wrote:
> Kees Cook writes:
> > Hi,
> >
> > This refactors the seccomp selftest macros used in change_syscall(),
> > in an effort to remove special cases for mips, arm, arm64, and xtensa,
> > whic
On Mon, Sep 14, 2020 at 03:47:13PM +1000, Michael Ellerman wrote:
> Kees Cook writes:
> > Some archs (like ppc) only support changing the return code during
> > syscall exit when ptrace is used. As the syscall number might not
> > be available anymore during syscall exit,
ynamic.o' being placed in section `.ctors.65435'
> [...]
Hmm, I wasn't seeing that...
Which gcc and bintuils versions are you using?
> Probably exposed by commit
>
> 83109d5d5fba ("x86/build: Warn on orphan section placement")
Very likely! :)
--
Kees Cook
On Sun, Sep 13, 2020 at 09:54:34PM +0200, Thomas Gleixner wrote:
> On Sat, Sep 12 2020 at 10:52, Kees Cook wrote:
> >> [ cut here ]
> >> syscall 56 left IRQs disabled
> >
> > This WARN appears reachable. :)
>
> The above is hardly a p
On Sun, Sep 13, 2020 at 08:27:23PM +0200, Thomas Gleixner wrote:
> On Sun, Sep 13 2020 at 17:44, Michael Ellerman wrote:
> > Kees Cook writes:
> > diff --git a/kernel/entry/common.c b/kernel/entry/common.c
> > index 18683598edbc..901361e2f8ea 100644
> > --- a/kern
ll 56 left IRQs disabled
This WARN appears reachable. :)
I also see on the dashboard these other problems with the new entry
code:
https://syzkaller.appspot.com/bug?extid=d4336c84ed0099fdbe47
https://syzkaller.appspot.com/bug?extid=c4af95386364bc59b13e
I can't tell if any of these have been looked at yet, though.
--
Kees Cook
To avoid an xtensa special-case, refactor all arch register macros to
take the register variable instead of depending on the macro expanding
as a struct member name.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 97 +--
1 file changed, 47
With all architectures now using the common SYSCALL_NUM_SET() macro, the
arch-specific #ifdef can be removed from change_syscall() itself.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff
Suggested-by: Thadeu Lima de Souza Cascardo
Link:
https://lore.kernel.org/linux-kselftest/20200911181012.171027-1-casca...@canonical.com/
Fixes: 58d0a862f573 ("seccomp: add tests for ptrace hole")
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_
Remove the arm64 special-case in change_syscall().
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests
Remove the mips special-case in change_syscall().
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp
As the UAPI headers start to appear in distros, we need to avoid
outdated versions of struct clone_args to be able to test modern
features. Additionally pull in the syscall numbers correctly.
Signed-off-by: Kees Cook
---
I needed to fix this to get MIPS to build the seccomp selftests
...@canonical.com/
Fixes: 5d83c2b37d43 ("selftests/seccomp: Add powerpc support")
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing
ut an associated SYSCALL_RET() macro. This also paves the way for
architectures that need to do special things to set the return value
(e.g. powerpc).
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 33 +--
1 file changed, 23 insertions(+), 10 dele
The __NR_mknod syscall doesn't exist on arm64 (only __NR_mknodat).
Switch to the modern syscall.
Fixes: ad5682184a81 ("selftests/seccomp: Check for EPOLLHUP for user_notif")
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
1 file changed, 1
Consolidate the REGSET logic into the new ARCH_GETREG() and
ARCH_SETREG() macros, avoiding more #ifdef code in function bodies.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 42 +++
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a
When none of the registers have changed, don't flush them back. This can
happen if the architecture uses a non-register way to change the syscall
(e.g. arm64) , and a return value hasn't been written.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 6
Instead of having the mips O32 macro special-cased, pull the logic into
the SYSCALL_NUM() macro. Additionally include the ABI headers, since
these appear to have been missing, leaving __NR_O32_Linux undefined.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 18
In order to avoid "#ifdef"s in the main function bodies, create a new
macro, SYSCALL_NUM_SET(), where arch-specific logic can live.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
di
Instead of special-casing the get/set-registers routines, move the
HAVE_GETREG logic into the new ARCH_GETREG() and ARCH_SETREG() macros.
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 27 ++-
1 file changed, 15 insertions(+), 12 deletions(-)
diff
Remove the arm special-case in change_syscall().
Signed-off-by: Kees Cook
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
b/tools/testing/selftests/seccomp
arm64, and i386 selftests shortly,
but I currently don't have an easy way to check xtensa, mips, nor
powerpc. Any help there would be appreciated!
(FWIW, I expect to take these via the seccomp tree.)
Thanks,
-Kees
Kees Cook (15):
selftests/seccomp: Refactor arch register macros
On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> On Thu, 10 Sep 2020, Kees Cook wrote:
>
> > [kees: re-sending this series on behalf of John Wood
> > also visible at https://github.com/johwood/linux fbfam]
> >
> > From: John Wood
>
> Why a
nd patch series?
Please feel free! I'm happy to help. :)
> My goal is to learn as much as possible doing something useful for the
> linux kernel.
Sounds good; thanks!
--
Kees Cook
Cc: Andy Lutomirski
Cc: Ingo Molnar
Signed-off-by: Kees Cook
---
kernel/entry/common.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/entry/common.c b/kernel/entry/common.c
index 18683598edbc..6fdb6105e6d6 100644
--- a/kernel/entry/common.c
+++ b/kernel/entr
llocation fails
.mailmap | 1 +
MAINTAINERS | 2 +-
kernel/seccomp.c | 24 ++--
3 files changed, 20 insertions(+), 7 deletions(-)
--
Kees Cook
perf-$VER record -e raw_syscalls:sys_enter -e raw_syscalls:sys_exit &
# ./seccomp_bpf
# fg
ctrl-c
# ./perf-$VER script | grep seccomp_bpf | awk '{print $7}' | sort | uniq -c >
$VER.log
*repeat*
# diff -u old.log new.log
...
(Is there an easier way to get those results?)
I will go see if I can figure out the best way to correct this.
--
Kees Cook
changes for feedback. I was
surprised to find the changes in the seccomp selftests today in Linus's
tree. I didn't seem to get CCed on this series, even though
get_maintainers shows this:
$ ./scripts/get_maintainer.pl 0001-selftests-seccomp-add-xtensa-support.mbox
Kees Cook (supporter:
es the syscall number on
> entry eg. in __audit_syscall_entry(). So it will record the wrong
> syscall happening in this case I think.
>
> Seems like we should reload the syscall number before calling
> trace_sys_enter() & audit ?
Agreed. I wonder what the best way to build a regression test for this
is... hmmm.
--
Kees Cook
On Thu, Sep 10, 2020 at 01:21:01PM -0700, Kees Cook wrote:
> From: John Wood
>
> The goal of this patch serie is to detect and mitigate a fork brute force
> attack.
Thanks for this RFC! I'm excited to get this problem finally handled in
the kernel. Hopefully the feedback is use
On Thu, Sep 10, 2020 at 01:21:07PM -0700, Kees Cook wrote:
> From: John Wood
>
> In order to mitigate a fork brute force attack it is necessary to kill
> all the offending tasks. This tasks are all the ones that share the
> statistical data with the current task (the task t
On Thu, Sep 10, 2020 at 01:21:06PM -0700, Kees Cook wrote:
> From: John Wood
>
> To detect a fork brute force attack it is necessary to compute the
> crashing rate of the application. This calculation is performed in each
> fatal fail of a task, or in other words, when a core du
On Thu, Sep 10, 2020 at 01:21:04PM -0700, Kees Cook wrote:
> From: John Wood
>
> Use the previous defined api to manage statistics calling it accordingly
> when a task forks, calls execve or exits.
>
> Signed-off-by: John Wood
> ---
> fs/exec.c | 2 ++
> ker
On Thu, Sep 10, 2020 at 01:21:03PM -0700, Kees Cook wrote:
> From: John Wood
>
> Create a statistical data structure to hold all the necessary
> information involve in a fork brute force attack. This info is a
> timestamp for the first fork or execve and the number of crash
On Thu, Sep 10, 2020 at 01:21:02PM -0700, Kees Cook wrote:
> From: John Wood
>
> Add a menu entry under "Security options" to enable the "Fork brute
> force attack mitigation" feature.
>
> Signed-off-by: John Wood
> ---
> security/Kconfig
On Thu, Sep 10, 2020 at 01:21:05PM -0700, Kees Cook wrote:
> From: John Wood
>
> This is a previous step to add the detection feature.
>
> A fork brute force attack will be detected when an application crashes
> quickly. Since, a rate can be defined as a time per fault, add
From: John Wood
Add a menu entry under "Security options" to enable the "Fork brute
force attack mitigation" feature.
Signed-off-by: John Wood
---
security/Kconfig | 1 +
security/fbfam/Kconfig | 10 ++
2 files changed, 11 insertions(+)
create mode 100644 security/fbfam/Kconfig
From: John Wood
This is a previous step to add the detection feature.
A fork brute force attack will be detected when an application crashes
quickly. Since, a rate can be defined as a time per fault, add a new
sysctl to control the crashing rate threshold.
This way, each system can tune the det
From: John Wood
Create a statistical data structure to hold all the necessary
information involve in a fork brute force attack. This info is a
timestamp for the first fork or execve and the number of crashes since
then. Moreover, due to this statitistical data will be shared between
different tas
From: John Wood
In order to mitigate a fork brute force attack it is necessary to kill
all the offending tasks. This tasks are all the ones that share the
statistical data with the current task (the task that has crashed).
Since the attack detection is done in the function fbfam_handle_attack()
From: John Wood
To detect a fork brute force attack it is necessary to compute the
crashing rate of the application. This calculation is performed in each
fatal fail of a task, or in other words, when a core dump is triggered.
If this rate shows that the application is crashing quickly, there is
[kees: re-sending this series on behalf of John Wood
also visible at https://github.com/johwood/linux fbfam]
From: John Wood
The goal of this patch serie is to detect and mitigate a fork brute force
attack.
Attacks with the purpose to break ASLR or bypass canaries traditionaly use
some level
From: John Wood
Use the previous defined api to manage statistics calling it accordingly
when a task forks, calls execve or exits.
Signed-off-by: John Wood
---
fs/exec.c | 2 ++
kernel/exit.c | 2 ++
kernel/fork.c | 4
3 files changed, 8 insertions(+)
diff --git a/fs/exec.c b/fs/exec
d include a link in the checkpatch
warning to it? (Feel free to just reuse the text removed from
deprecated.rst)
--
Kees Cook
rch/*/kernel/module.lds to arch/*/include/asm/module.lds.h,
> which is included from scripts/module.lds.S.
>
> scripts/module.lds is fine because 'make clean' keeps all the build
> artifacts under scripts/.
>
> You can add arch-specific sections in .
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Kees Cook
--
Kees Cook
This adds explicit mailmap entries for my older/other email addresses.
Reported-by: Joe Perches
Signed-off-by: Kees Cook
---
.mailmap | 4
1 file changed, 4 insertions(+)
diff --git a/.mailmap b/.mailmap
index 50096b96c85d..a780211468e4 100644
--- a/.mailmap
+++ b/.mailmap
@@ -169,6
On Thu, Sep 10, 2020 at 05:05:24AM -0400, Miaohe Lin wrote:
> Fix some weird and confusing comments.
>
> Signed-off-by: Miaohe Lin
Reviewed-by: Kees Cook
--
Kees Cook
een vanilla and CONFIG_UBSAN_TRAP'ed kernels. In particular,
> this will help enabling bounds sanitizer transparently for Android's
> GKI.
>
> Signed-off-by: Elena Petrova
Acked-by: Kees Cook
(This should be CCed to akpm who has been taking most of the ubsan
patches lately.)
--
Kees Cook
On Fri, Sep 04, 2020 at 11:31:04AM +0200, pet...@infradead.org wrote:
> On Thu, Sep 03, 2020 at 03:03:30PM -0700, Sami Tolvanen wrote:
> > On Thu, Sep 3, 2020 at 2:51 PM Kees Cook wrote:
> > >
> > > On Thu, Sep 03, 2020 at 01:30:30PM -0700, Sami Tolvanen wrote:
&
example, these are some:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=Control+Flow+Integrity
[2]
https://lore.kernel.org/lkml/20200624203200.78870-1-samitolva...@google.com/T/#m6b576c3af79bdacada10f21651a2b02d33a4e32e
[3]
https://android-developers.googleblog.com/2018/10/control-flow-integrity-in-android-kernel.html
--
Kees Cook
orcement of the symbol visibility.
Fixes: 548193cba2a7 ("test_firmware: add support for firmware_request_platform")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
This is split out from the larger kernel_read_file series:
https://lore.kernel.org/lkml/20200729175845.174547
uot;)
>
> {sigh}
>
> I'll go revert this, sorry about that.
>
> Kees, can you fix up this whole series and resend it again? I'm
> dropping it from my trees now...
Oh ew, I will check the configs. I wonder what went wrong with this...
sorry for the noise!
--
Kees Cook
Instead of full GNU diff (which smaller boot environments may not have),
use "comm" which is more available.
Reported-by: Naresh Kamboju
Cc: Shuah Khan
Cc: linux-kselft...@vger.kernel.org
Fixes: f131d9edc29d ("selftests/lkdtm: Don't clear dmesg when running tests")
On Wed, Sep 09, 2020 at 04:29:50PM -0400, Joe Lawrence wrote:
> On 9/9/20 3:49 PM, Kees Cook wrote:
> >
> > On Fri, Jun 26, 2020 at 01:59:43PM -0700, Kees Cook wrote:
> > > Instead of full GNU diff (which smaller boot environments may not have),
> > > u
On Fri, Jun 26, 2020 at 01:59:43PM -0700, Kees Cook wrote:
> Instead of full GNU diff (which smaller boot environments may not have),
> use "comm" which is more available.
>
> Reported-by: Naresh Kamboju
> Link:
> https://lore.kernel.org/lkml/ca+g9fythp+gg+brr_gk
f-by: Gustavo A. R. Silva
Looks great!
Acked-by: Kees Cook
--
Kees Cook
hy do these two warnings occur every time I compiled?
Hi!
I think the samples have been a bit ignored lately because they have a
lot of weird build issues with regard to native vs compat and needing
the kernel headers to be built first, etc.
That said, yes, I'd like to fix warnings. However, I can't reproduce
this. How are you building? I tried x86_64 and cross-compiled to i386.
--
Kees Cook
mpile rules.
> # TEST_CUSTOM_PROGS should be used by tests that require
> # custom build rule and prevent common build rule use.
*thread necromancy*
I think this is fixed in the selftest tree itself now (though
differently), in that it depends on having build the headers first.
Anyway, please let me know if this is still a problem, and I'll take
another look (and hopefully I also won't lose the thread for a year...)
Thanks!
--
Kees Cook
NING: sum of
> probable bitmasks, consider |
Applied, thanks!
[1/1] selftests/seccomp: Use bitwise instead of arithmetic operator for flags
https://git.kernel.org/kees/c/76993fe3c1e4
Sorry for the massive delay on this one! I lost this email in my inbox. :)
--
Kees Cook
kees/c/4484dbacd7b6
I reworded your commit based on the thread and added one comment for
a weird case where task == current, hopefully that looks correct:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/seccomp&id=4484dbacd7b61eaa4e21332c0a044dedce732ebb
--
Kees Cook
801 - 900 of 5544 matches
Mail list logo
