Applied, thanks!
[1/2] seccomp: don't leak memory when filter install races
https://git.kernel.org/kees/c/a566a9012acd
[2/2] mailmap, MAINTAINERS: move to tycho.pizza
https://git.kernel.org/kees/c/19d1d49f2a8c
Best regards,
--
Kees Cook
->notif if file allocation fails
https://git.kernel.org/kees/c/e839317900e9
as featured on my Twitch stream! ;)
--
Kees Cook
NSTRUMENT_string.o := n
> > KASAN_SANITIZE_string.o := n
> > +UBSAN_SANITIZE_string.o := n
> > +KCSAN_SANITIZE_string.o := n
>
> Ouch.
>
> We have found manifestations of bugs in lib/string.c functions, e.g.:
>
> https://groups.google.com/forum/#!msg/syzkaller-bugs/atbKWcFqE9s/x7AtoVoBAgAJ
>
> https://groups.google.com/forum/#!msg/syzkaller-bugs/iGBUm-FDhkM/chl05uEgBAAJ
>
> Is there any way this can be avoided?
Agreed: I would like to keep this instrumentation; it's a common place
to find bugs, security issues, etc.
--
Kees Cook
The following commit has been merged into the core/build branch of tip:
Commit-ID: 4409d2f8dfe7d5088567d4ba00133f876ee586c7
Gitweb:
https://git.kernel.org/tip/4409d2f8dfe7d5088567d4ba00133f876ee586c7
Author:Kees Cook
AuthorDate:Tue, 01 Sep 2020 19:53:45 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: b3e5d80d0c48c0cc7bce56473672f4e6e1210910
Gitweb:
https://git.kernel.org/tip/b3e5d80d0c48c0cc7bce56473672f4e6e1210910
Author:Kees Cook
AuthorDate:Tue, 01 Sep 2020 19:53:43 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 83109d5d5fba7abf362f5a443c9f4c4ea10bbc8d
Gitweb:
https://git.kernel.org/tip/83109d5d5fba7abf362f5a443c9f4c4ea10bbc8d
Author:Kees Cook
AuthorDate:Tue, 01 Sep 2020 19:53:46 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 5a17850e251a55bba6d65aefbfeacfa9888cd2cd
Gitweb:
https://git.kernel.org/tip/5a17850e251a55bba6d65aefbfeacfa9888cd2cd
Author:Kees Cook
AuthorDate:Tue, 01 Sep 2020 19:53:44 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 6e0bf0e0e55000742a53c5f3b58f8669e0091a11
Gitweb:
https://git.kernel.org/tip/6e0bf0e0e55000742a53c5f3b58f8669e0091a11
Author:Kees Cook
AuthorDate:Tue, 01 Sep 2020 19:53:47 -07:00
Committer
On Sun, Sep 06, 2020 at 12:08:09PM -0400, Arvind Sankar wrote:
> On Sun, Sep 06, 2020 at 03:06:29AM -0700, Kees Cook wrote:
> > Fix the language around return values to indicate destination instead of
> > source.
> >
> > Reported-by: Masahiro Yamada
> > Link:
Fix the language around return values to indicate destination instead of
source.
Reported-by: Masahiro Yamada
Link:
https://lore.kernel.org/lkml/CAK7LNAQvQBhjYgSkvm-dVyNz2Jd2C2qAtfyRk-rngEDfjkc38g
Cc: Nick Desaulniers
Signed-off-by: Kees Cook
---
This is a fix for lib-stringc-implement
s:
>
> The strcpy() and strncpy() functions return
> a pointer to the destination string *dest*.
Agreed; that's a typo.
--
Kees Cook
On Fri, Sep 04, 2020 at 07:58:25AM +0200, Ingo Molnar wrote:
>
> * Nick Desaulniers wrote:
>
> > On Tue, Sep 1, 2020 at 7:53 PM Kees Cook wrote:
> > >
> > > Hi Ingo,
> > >
> > > The ever-shortening series. ;) Here is "v7", which
s tree can be found at either of these places:
https://github.com/samitolvanen/linux/commits/clang-lto
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git kspp/sami/lto/v2
--
Kees Cook
On Thu, Sep 03, 2020 at 01:30:25PM -0700, Sami Tolvanen wrote:
> This patch series adds support for building x86_64 and arm64 kernels
> with Clang's Link Time Optimization (LTO).
Tested-by: Kees Cook
FWIW, this gives me a happy booting x86 kernel:
# cat /proc/version
Linux versio
ess, it's needed to make
it work, so:
Reviewed-by: Kees Cook
--
Kees Cook
LTO? (Or is this an LLVM integrated
assembler-ism?) Regardless, yes, let's nail it down:
Reviewed-by: Kees Cook
--
Kees Cook
t; the small amount of C code.
>
> Signed-off-by: Sami Tolvanen
Moar DISABLE_LTO...
Reviewed-by: Kees Cook
--
Kees Cook
>
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
On Thu, Sep 03, 2020 at 01:30:50PM -0700, Sami Tolvanen wrote:
> Allow CONFIG_LTO_CLANG and CONFIG_THINLTO to be enabled.
>
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
Does it depend on the earlier mcount fixes?
Reviewed-by: Kees Cook
--
Kees Cook
he non-functional DISABLE_LTO...)
Reviewed-by: Kees Cook
--
Kees Cook
: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
n
Reviewed-by: Kees Cook
--
Kees Cook
e strips the unnecessary .lto suffix from the module name.
>
> Suggested-by: Bill Wendling
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
mbly. This
> change adds a global stub with a stable name for each initcall to
> fix the issue when PREL32 relocations are used.
>
> Signed-off-by: Sami Tolvanen
This was a Delight(tm) to get right. Thanks for finding the right magic
here. :)
Reviewed-by: Kees Cook
--
Kees Cook
ne assembly. This change adds a global stub to
> DECLARE_PCI_FIXUP_SECTION to fix the issue when PREL32 relocations
> are used.
>
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
+ my $section;
> +
> + if ($level eq 'con') {
> + $section = '.con_initcall.init';
> + } else {
> + $section = ".initcall${level}.init";
> + }
> +
> + print "\t${section} : {\n";
> +
> + foreach my $secname (@{$sections->{$level}}) {
> + print "\t\t*(${section}..${secname}) ;\n";
> + }
> +
> + print "\t}\n";
> + }
> +
> + print "}\n";
> +}
> +
> +generate_initcall_lds();
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index a352a5ad9ef7..1d5730176bed 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -43,6 +43,16 @@ info()
> fi
> }
>
> +# Generate a linker script to ensure correct ordering of initcalls.
> +gen_initcalls()
> +{
> + info GEN .tmp_initcalls.lds
> +
> + ${srctree}/scripts/generate_initcall_order.pl \
> + ${KBUILD_VMLINUX_OBJS} ${KBUILD_VMLINUX_LIBS} \
> + > .tmp_initcalls.lds
> +}
> +
> # If CONFIG_LTO_CLANG is selected, collect generated symbol versions into
> # .tmp_symversions.lds
> gen_symversions()
> @@ -74,6 +84,9 @@ modpost_link()
> --end-group"
>
> if [ -n "${CONFIG_LTO_CLANG}" ]; then
> + gen_initcalls
> + lds="-T .tmp_initcalls.lds"
Oh, I think lds should be explicitly a "local" at the start of this
function, perhaps back in the symversions patch that touches this?
> +
> if [ -n "${CONFIG_MODVERSIONS}" ]; then
> gen_symversions
> lds="${lds} -T .tmp_symversions.lds"
> @@ -285,6 +298,7 @@ cleanup()
> {
> rm -f .btf.*
> rm -f .tmp_System.map
> + rm -f .tmp_initcalls.lds
> rm -f .tmp_symversions.lds
> rm -f .tmp_vmlinux*
> rm -f System.map
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
--
Kees Cook
akes .mod files smaller and
> easier to read.
>
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
i Tolvanen
We'll likely need to come back around to this for FGKASLR (to keep the
.text.* sections separated), but that's no different than the existing
concerns for FGKASLR on the main kernel.
Reviewed-by: Kees Cook
--
Kees Cook
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
--
Kees Cook
> +
> + if [ -n ${USE_OBJTOOL_MCOUNT} ]; then
> + objtoolopt="${objtoolopt} --mcount"
> + fi
> + fi
> +
> if [ -n "${CONFIG_VMLINUX_VALIDATION}" ]; then
> - objtoolopt="check --vmlinux"
> + if [ -z "${objtoolopt}" ]; then
> + objtoolopt="check --vmlinux"
> + else
> + objtoolopt="${objtoolopt} --vmlinux"
> + fi
> + fi
> +
> + if [ -n "${objtoolopt}" ]; then
> if [ -z "${CONFIG_FRAME_POINTER}" ]; then
> objtoolopt="${objtoolopt} --no-fp"
> fi
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
--
Kees Cook
is it noticeably slower to
do it this way under non-LTO?)
Reviewed-by: Kees Cook
--
Kees Cook
easy for
GCC LTO support to get added when someone steps up to do it. The bulk of
the changed needed to support GCC LTO are part of this series already,
since the build problems involving non-ELF .o files and init ordering
are shared by Clang and GCC AFAICT.
Reviewed-by: Kees Cook
--
Kees Cook
nd that this fixes mcount for Clang generally
(i.e. it's not _strictly_ related to LTO, though LTO depends on this
change)? And does this mean mcount was working for gcc < 5?
Reviewed-by: Kees Cook
--
Kees Cook
do all
of the tooling detection in the Kconfig, but that's a larger issues and
orthogonal to this fix, IMO.)
Reviewed-by: Kees Cook
--
Kees Cook
nen
Looks right to me.
Reviewed-by: Kees Cook
--
Kees Cook
be defined
> in Makefile.
>
> Link:
> https://lore.kernel.org/lkml/20200625200235.gq4...@hirez.programming.kicks-ass.net/
> Signed-off-by: Peter Zijlstra
Hmm, I'm not sure why this hasn't gotten picked up yet. Is this expected
to go through -tip or something else?
Reviewed-by: Kees Cook
--
Kees Cook
403nd ("x86/mce: Convert the CEC to use the MCE notifier")
> Signed-off-by: Luca Stefani
I don't see this in -next yet (next-20200903), but given Boris's SoB, I
suspect it just hasn't snuck it's way there from -tip. Regardless:
Reviewed-by: Kees Cook
--
Kees Cook
sted-by: Andy Lavr
> Suggested-by: Arvind Sankar
> Suggested-by: Joe Perches
> Suggested-by: Masahiro Yamada
> Suggested-by: Rasmus Villemoes
> Signed-off-by: Nick Desaulniers
As you mentioned, this is in -next already (via -mm). I think I sent a
tag for this before, but maybe akpm missed it, so for good measure:
Reviewed-by: Kees Cook
--
Kees Cook
g reordered across writes, while allowing memory loads to be
> cached/reordered across CRn reads, which should be safe.
>
> Signed-off-by: Arvind Sankar
In the primary thread for this patch I sent a Reviewed tag, but for good
measure, here it is again:
Reviewed-by: Kees Cook
--
Kees Cook
/x86-64-ABI/linker-optimization.tex#L65
> [1]
> https://lore.kernel.org/lkml/20200807194100.3570838-1-ndesaulni...@google.com/
> [2] https://github.com/ClangBuiltLinux/linux/issues/1121
> [3] https://reviews.llvm.org/rGc41a18cf61790fc898dcda1055c3efbf442c14c0
> [4]
> https://lore.kernel.org/lkml/20200731202738.2577854-1-nived...@alum.mit.edu/
>
> Reported-by: Nick Desaulniers
> Signed-off-by: Arvind Sankar
Reviewed-by: Kees Cook
--
Kees Cook
hile allowing memory loads to be
> cached/reordered across CRn reads, which should be safe.
>
> Tested-by: Nathan Chancellor
> Tested-by: Sedat Dilek
> Signed-off-by: Arvind Sankar
Seems reasonable to me. As reasonable as compiler bug workarounds
go, that is. ;)
Reviewed-by: Kees Cook
--
Kees Cook
: { *(.dynamic) } :text :dynamic
> - .got: { *(.got) } :text
> .plt: { *(.plt) }
>
> _end = .;
> @@ -108,7 +107,9 @@ SECTIONS
> .debug_varnames 0 : { *(.debug_varnames) }
>
> /DISCARD/ : {
> + *(.got)
> *(.note.GNU-stack)
> + *(.branch_lt)
> *(.data .data.* .gnu.linkonce.d.* .sdata*)
> *(.bss .sbss .dynbss .dynsbss)
> *(.glink .iplt .plt .rela*)
> --
> 2.28.0.402.g5ffc5be6b7-goog
>
--
Kees Cook
l.org/lkml/20200622205815.2988115-1-keesc...@chromium.org/
v1: https://lore.kernel.org/lkml/20200228002244.15240-1-keesc...@chromium.org/
Kees Cook (5):
arm64/build: Warn on orphan section placement
arm/build: Warn on orphan section placement
arm/boot: Warn on orphan section placement
x86/build: Warn on orph
d: warning: orphan section `.fixup' from `arch/arm/lib/copy_from_user.o' being
placed in section `.fixup'
With all sections handled, enable orphan section warning.
Reviewed-by: Nick Desaulniers
Signed-off-by: Kees Cook
---
arch/arm/Makefile | 4
1 file changed, 4 insertions(
ill Deacon
Signed-off-by: Kees Cook
---
arch/arm64/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 6de7f551b821..081144fcc3da 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -29,6 +29,10 @@ LDFLAGS_vmlinux += --fix-
We don't want to depend on the linker's orphan section placement
heuristics as these can vary between linkers, and may change between
versions. All sections need to be explicitly handled in the linker script.
With all sections now handled, enable orphan section warning.
Signed-off-by:
s.
Signed-off-by: Kees Cook
---
arch/x86/boot/compressed/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/boot/compressed/Makefile
b/arch/x86/boot/compressed/Makefile
index 5b7f6e175b03..871cc071c925 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compresse
s.
Signed-off-by: Kees Cook
---
arch/x86/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 4346ffb2e39f..154259f18b8b 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -209,6 +209,10 @@ ifdef CONFIG_X86_64
LDFLAGS_vmlinux += -z max
On Tue, Sep 01, 2020 at 11:02:02AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 1, 2020 at 8:17 AM Kees Cook wrote:
> >
> > On Tue, Sep 01, 2020 at 10:16:47AM +0200, Ingo Molnar wrote:
> > > > This is with:
> > > >
> > > > GNU ld version 2.25-
>
> Next are a series of reverts. One for 32b arm is a partial revert.
>
> Then Marco suggested fixes to KASAN docs.
>
> Finally, improve the warning for GCC too as per Kees.
> [...]
> 8 files changed, 16 insertions(+), 27 deletions(-)
A nice simplification!
Reviewed-by
gt;
> > So don't make the code uglier just to maintain a fiction that
> > something is tested when it isn't really.
>
> Sure fine with me unless Kees screams.
To clarify: if any of x86, arm64, arm, powerpc, riscv, and s390 are
using set_fs(), I want to keep this test. "ugly" is fine in lkdtm. :)
--
Kees Cook
gt;
> > So don't make the code uglier just to maintain a fiction that
> > something is tested when it isn't really.
>
> Sure fine with me unless Kees screams.
If we don't have set_fs, we don't need the tests. :)
--
Kees Cook
On Tue, Sep 01, 2020 at 10:16:47AM +0200, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
> >
> > * Ingo Molnar wrote:
> >
> > >
> > > * Kees Cook wrote:
> > >
> > > > On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook
On Mon, Aug 31, 2020 at 07:14:59PM -0600, Tycho Andersen wrote:
> On Mon, Aug 31, 2020 at 06:09:15PM -0600, Tycho Andersen wrote:
> > On Mon, Aug 31, 2020 at 04:25:35PM -0700, Kees Cook wrote:
> > > On Sun, Aug 30, 2020 at 08:50:15PM -0700, syzbot wrote:
> > > > syz
The following commit has been merged into the core/build branch of tip:
Commit-ID: 7e8c4ed2638d08a1604c87b60ed7161bf92e6f86
Gitweb:
https://git.kernel.org/tip/7e8c4ed2638d08a1604c87b60ed7161bf92e6f86
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:01 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 512dd2eebe5585893412e0c8bec8dbfe2dead6c8
Gitweb:
https://git.kernel.org/tip/512dd2eebe5585893412e0c8bec8dbfe2dead6c8
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:58 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 815d680771ae09080d2da83dac2647c08cdf99ce
Gitweb:
https://git.kernel.org/tip/815d680771ae09080d2da83dac2647c08cdf99ce
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:04 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: d812db78288d76d1e8c6df3a840c41a8875f6468
Gitweb:
https://git.kernel.org/tip/d812db78288d76d1e8c6df3a840c41a8875f6468
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:44 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 7cf891a40057f851af74e68bacb01b90bd775b5d
Gitweb:
https://git.kernel.org/tip/7cf891a40057f851af74e68bacb01b90bd775b5d
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:07 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: b4ca91027d8226ae423ce498f03f5b348cf84e36
Gitweb:
https://git.kernel.org/tip/b4ca91027d8226ae423ce498f03f5b348cf84e36
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:49 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 414d2ff5e5f21049b6b242271a6a8579f9dffc1b
Gitweb:
https://git.kernel.org/tip/414d2ff5e5f21049b6b242271a6a8579f9dffc1b
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:09 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: d1c0272bc1c068f8c2cb3d1b395173602b0df6e7
Gitweb:
https://git.kernel.org/tip/d1c0272bc1c068f8c2cb3d1b395173602b0df6e7
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:08 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: dfbe69689b4dee19021d8c315a5137b4790b5634
Gitweb:
https://git.kernel.org/tip/dfbe69689b4dee19021d8c315a5137b4790b5634
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:43 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: be2881824ae9eb92a35b094f734f9ca7339ddf6d
Gitweb:
https://git.kernel.org/tip/be2881824ae9eb92a35b094f734f9ca7339ddf6d
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:54 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: a850958c072404f75dd41782cb4ff34b8625b47d
Gitweb:
https://git.kernel.org/tip/a850958c072404f75dd41782cb4ff34b8625b47d
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:03 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 0c918e753f8c03b0308a635c0721a8c24d738d4a
Gitweb:
https://git.kernel.org/tip/0c918e753f8c03b0308a635c0721a8c24d738d4a
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:59 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 6e0a66d10c5b629369afa47b753d0ec46fa812dd
Gitweb:
https://git.kernel.org/tip/6e0a66d10c5b629369afa47b753d0ec46fa812dd
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:51 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 2883352bf801d093a04f269800b48bb8aa2515fb
Gitweb:
https://git.kernel.org/tip/2883352bf801d093a04f269800b48bb8aa2515fb
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:52 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 578d7f0fd6a5ec8a369a4537c664eb2c8374c134
Gitweb:
https://git.kernel.org/tip/578d7f0fd6a5ec8a369a4537c664eb2c8374c134
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:53 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: c604abc3f6e3030f3a3022b184ed7d3780c34d30
Gitweb:
https://git.kernel.org/tip/c604abc3f6e3030f3a3022b184ed7d3780c34d30
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:45 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: e2179a09ab089d3423751bd2b0c884ddb3eabe84
Gitweb:
https://git.kernel.org/tip/e2179a09ab089d3423751bd2b0c884ddb3eabe84
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:48 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 03c2b85cb7f13e9bd82cbe4201ede52177d433f5
Gitweb:
https://git.kernel.org/tip/03c2b85cb7f13e9bd82cbe4201ede52177d433f5
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:42 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: a840c4de569f610bc5ee043b613c35b779d23186
Gitweb:
https://git.kernel.org/tip/a840c4de569f610bc5ee043b613c35b779d23186
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:46 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 34b4a5c54c429d12bcc783a27650752237c49a36
Gitweb:
https://git.kernel.org/tip/34b4a5c54c429d12bcc783a27650752237c49a36
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:50 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: d7e3b065dc98e95f2dae6d2da031dd4c243bd7be
Gitweb:
https://git.kernel.org/tip/d7e3b065dc98e95f2dae6d2da031dd4c243bd7be
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:56 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 3b14aefb84320ac430cecbdc87b680317916b2bd
Gitweb:
https://git.kernel.org/tip/3b14aefb84320ac430cecbdc87b680317916b2bd
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:42:57 -07:00
Committer
The following commit has been merged into the core/build branch of tip:
Commit-ID: 5354e84598f264793265cc99b4be2a2295826c86
Gitweb:
https://git.kernel.org/tip/5354e84598f264793265cc99b4be2a2295826c86
Author:Kees Cook
AuthorDate:Fri, 21 Aug 2020 12:43:05 -07:00
Committer
t's not call them "_integration_kunit.c" ;) _behavior.c?
_integration.c?
> Do you know of any cases where something has/would have both
> unit-style tests and integration-style tests built with KUnit where
> the distinction needs to be clear?
This is probably the right question. :)
--
Kees Cook
_release() was never called *and* seccomp_filter_free()
got called... which would imply a reference counting problem. The way
there doesn't jump out at me yet, but I haven't yet decoded the C
reproducer into the actual seccomp arguments, etc.
--
Kees Cook
On Fri, Aug 21, 2020 at 12:42:41PM -0700, Kees Cook wrote:
> Hi Ingo,
>
> Based on my testing, this is ready to go. I've reviewed the feedback on
> v5 and made a few small changes, noted below.
If no one objects, I'll pop this into my tree for -next. I'd prefer it
go
_group_exit(SIGSYS);
I need to think a little more, but I suspect we should change the coredump
logic (above the quoted code) too... (i.e. "action == SECCOMP_RET_KILL_PROCESS"
-> "action != SECCOMP_RET_KILL_THREAD")
> }
>
> unreachable();
> --
> 2.21.0
>
Thanks!
-Kees
--
Kees Cook
would be excellent.
> 2. Determine if there are places in the build Makefiles that do rely on
> the executable bit and fix those script invocations. (Kees' idea of remove
> all executable bits and see...)
I think this has value, yes. I don't think patches to remove the x bits
are needed, but any cases where they are depended on need to be fixed.
And I think "3" could be "wire up or remove spdx shell script"
--
Kees Cook
+ return 0;
This can be:
if (WARN(pos < buf, "pos < buf\n") ||
WARN(pos - buf >= PAGE_SIZE, "pos >= PAGE_SIZE (%tu > %lu)\n",
pos - buf, PAGE_SIZE))
return 0;
--
Kees Cook
.) In order to
eliminate bug classes, we need remove the APIs that are foot-guns. Even
if one developer never gets it wrong, others might.
[1]
https://lore.kernel.org/lkml/c256eba42a564c01a8e470320475d...@acums.aculab.com/T/#mac95487d7ae427de03251b49b75dd4de40c2462d
--
Kees Cook
;fmt", var args ...);
remaining -= scnprintf(buf, remaining, "fmt", var args ...);
return PAGE_SIZE - remaining;
}
--
Kees Cook
isdn/mISDN/core.c-}
> > > drivers/isdn/mISDN/core.c-static DEVICE_ATTR_RO(name);
> >
> > That form ends up calculating the string length twice.
> > Better would be:
> > len = strlen(msg);
> > memcpy(buf, msg, len);
> > return len;
>
> or given clang's requirement for stpcpy
>
> return stpcpy(buf, dev_name(dev)) - buf;
>
> (I do not advocate for this ;)
Heh. And humans aren't allowed to use stpcpy() in the kernel. :)
--
Kees Cook
with _sizeof_ and all the way it goes terribly wrong. So,
okay, I'm convinced. container_of() it is.
Doing these conversions becomes a little less mechanical if assignment
needs to be split from declaration, but hey, we've got a 100 character
line "limit" now, so maybe it'll be less needed. :)
--
Kees Cook
On Thu, Aug 27, 2020 at 12:37:03PM -0700, Joe Perches wrote:
> On Thu, 2020-08-27 at 11:30 -0700, Kees Cook wrote:
>
> > Most of the uses of strcpy() in the kernel are just copying between two
> > known-at-compile-time NUL-terminated character arrays. We had wanted to
> >
build tests, I run those with COMPILE_TEST force-enabled.
Ah, I got this backwards. It's not COMPILE_TEST breaking it, it's
actually FIXING it. :P Anyway, I'll go clean this up more.
--
Kees Cook
On Thu, Aug 27, 2020 at 12:02:12PM -0700, Linus Torvalds wrote:
> On Thu, Aug 27, 2020 at 11:42 AM Kees Cook wrote:
> >
> > Do you mean you checked both gcc and clang and it was only a problem with
> > gcc?
>
> I didn't check with clang, but Arnd claimed it was
mechanical step seems
like quite an overreaction.
But, yes, let's get the right API here. I think container_of() is a mess
for these 1-to-many cases. What do you suggest here? I'll change all of
from_timer() to use it too.
-Kees
[1] https://lore.kernel.org/lkml/20170928133817.GA113410@beast/
--
Kees Cook
CFLAGS_UBSAN += $(call cc-option, -fsanitize=object-size)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=bool)
CFLAGS_UBSAN += $(call cc-option, -fsanitize=enum)
endif
--
Kees Cook
for now, I'm aimed at removing strlcpy() completely first,
then look at strcpy() -> strscpy() for cases where target size is NOT
compile-time known, and then to convert the kernel's strcpy() into
_requiring_ that source/dest lengths are known at compile time.
And then tackle strncpy(), which is a mess.
--
Kees Cook
On Wed, Aug 26, 2020 at 07:42:17PM -0700, Joe Perches wrote:
> On Wed, 2020-08-26 at 19:33 -0700, Kees Cook wrote:
> > On Wed, Aug 26, 2020 at 04:57:41PM -0700, Joe Perches wrote:
> > > On Wed, 2020-08-26 at 16:38 -0700, Kees Cook wrote:
> > > > On Thu, Aug 27, 2020
.wiki.kernel.org/en/developers/documentation/submittingpatches
FWIW, I don't think a revert is needed here to wait for the from_tasket()
-> container_from() API to land since from_tasklet() is already being
used by other trees. Let's just get this done so we can get closer to
ripping out the old tasklet API. We'll have to do a treewide
from_timer(), from_tasklet() -> container_from() anyway...
--
Kees Cook
l if_changed,hypercalls)
And I can't even find anything in the kernel that calls
scripts/spdxcheck-test.sh :) I think that should likely be moved into
the selftests directory and wired up.
--
Kees Cook
here, based on the current
> security@k.o traffic, I doubt this will really change much :(
And given our relatively low traffic, I'd rather we (the
secur...@kernel.org folks) make the determination if things should be
public or private. We should be the ones on the hook for those judgement
calls, not the reporter reading our documentation. :)
--
Kees Cook
On Thu, Aug 27, 2020 at 02:19:41PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 26, 2020 at 07:31:40PM -0700, Kees Cook wrote:
> > On Thu, Aug 27, 2020 at 07:06:36AM +0530, Allen Pais wrote:
> > > Introduce container_from() as a generic helper instead of
> > > sub
vely", it all just works in a simple manner.
Later in this thread there's a suggestion to alter the API to avoid
individual calls to sprintf(), which seems like a reasonable first step.
-Kees
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11990a5bd7e558e9203c1070fc52fb6f0488e75b
--
Kees Cook
901 - 1000 of 5696 matches
Mail list logo
