This change switches SCS to use virtually mapped shadow stacks,
> which increases shadow stack size to a full page and provides more
> robust overflow detection similarly to VMAP_STACK.
>
> Signed-off-by: Sami Tolvanen
Thanks! I much prefer this to kmem. :)
Reviewed-by: Kees Cook
--
Kees Cook
On Thu, Oct 22, 2020 at 03:52:20PM -0500, YiFei Zhu wrote:
> 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
> >
ble
itself with BTI enabled by default. I prefer gaining Catalin's suggested
patch[2]. :)
[1]
https://lore.kernel.org/kernel-hardening/1562410493-8661-1-git-send-email-s.mesorac...@gmail.com/
[2] https://lore.kernel.org/linux-arm-kernel/20201022093104.GB1229@gaia/
--
Kees Cook
On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry Osipenko wrote:
> 22.10.2020 02:40, Kees Cook пишет:
> > On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry Osipenko wrote:
> >> The vfp_kmode_exception() function now is unreachable using relative
> >> branching in
VFP enabled?
> DBGSTR1 "fpexc %08x", r1
This seems like a workaround though? I suspect the vfp11_veneer needs
moving?
--
Kees Cook
On Thu, Oct 22, 2020 at 12:22:15AM +0200, Borislav Petkov wrote:
> On Wed, Oct 21, 2020 at 01:04:35PM -0700, Kees Cook wrote:
> > [thread ping: x86 maintainers, can someone please take this?]
>
> $ ./scripts/get_maintainer.pl -f include/asm-generic/vmlinux.lds.h
On Wed, Oct 14, 2020 at 09:53:39PM -0700, Fāng-ruì Sòng wrote:
> On Wed, Oct 14, 2020 at 4:04 PM Kees Cook wrote:
> > > index 5430febd34be..b83c00c63997 100644
> > > --- a/include/asm-generic/vmlinux.lds.h
> > > +++ b/include/asm-generic/vmlinux.lds.h
> >
[thread ping: x86 maintainers, can someone please take this?]
On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
> Under some circumstances, the compiler generates .ctors.* sections. This
> is seen doing a cross compile of x86_64 from a powerpc64el host:
>
> x86_64-linux-gnu
#x27;t belong in compiler.h.
>
> Signed-off-by: Arvind Sankar
> Fixes: 815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
> exclusive")
Yeowch.
Cc: sta...@vger.kernel.org
Reviewed-by: Kees Cook
Nick just mentioned this to me; I hadn't had a chance
t; [kees: Fixed up coredump selection logic to match]
> Signed-off-by: Kees Cook
> Signed-off-by: Sasha Levin
> ---
> kernel/seccomp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 676d4af62103
On Fri, Oct 16, 2020 at 01:12:24AM -0700, syzbot wrote:
> dashboard link: https://syzkaller.appspot.com/bug?extid=92ead4eb8e26a26d465e
> [...]
> Reported-by: syzbot+92ead4eb8e26a26d4...@syzkaller.appspotmail.com
> [...]
> UBSAN: array-index-out-of-bounds in crypto/af_alg.c:166:2
> index 91 is out o
n of the general reduction
in utility, I can live with it as long as it doesn't make other things
worse. :) I'll get this reviewed with specific feedback soon, but I'm
about to be EOW. ;)
--
Kees Cook
angerous code pattern, but it can mask finding them.
Then, at the end of the day, only the corner cases remain, and those can
be seen clearly as they change over time. Since we can never have a
one-time audit be anything other than advisory, we need to make it EASY
to do those kinds of audits so they can be done regularly.
--
Kees Cook
.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
--
Kees Cook
anic - not syncing: Attempted to kill init! exitcode=0x0009
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0009 ]---
>
> Fixes: 1b3a5d02ee07 ("reboot: move arch/x86 reboot= handling to generic
> kernel")
> Signed-off-by: Matteo Croce
Reviewed-by: Kees Cook
--
Kees Cook
The notes on replacing the deprecated str*cpy() functions didn't call
enough attention to the change in return type. Add these details and
clean up the language a bit more.
Signed-off-by: Kees Cook
---
Documentation/process/deprecated.rst | 44
1 file change
The details on using LKDTM were overly obscure. Modernize the details
and expand examples to better illustrate how to use the interfaces.
Additionally add missing SPDX header.
Signed-off-by: Kees Cook
---
.../fault-injection/provoke-crashes.rst | 56 +++
1 file changed, 33
On Thu, Oct 15, 2020 at 11:44:15AM +0200, Vlastimil Babka wrote:
> On 10/15/20 10:23 AM, Christopher Lameter wrote:
> > On Wed, 14 Oct 2020, Kees Cook wrote:
> >
> > > Note on patch 2: Christopher NAKed it, but I actually think this is a
> > > reasonable thing t
On Thu, Oct 15, 2020 at 02:57:34PM +0530, Naresh Kamboju wrote:
> On Tue, 29 Sep 2020 at 01:56, Kees Cook wrote:
> >
> > Currently with run_kselftest.sh there is no way to choose which test
> > we could run. All the tests listed in kselftest-list.txt are all run
>
gt;
> ...
> 54 mutex_lock(&sbi->pipe_mutex);
> 55 while (bytes) {
> 56 wr = __kernel_write(file, data, bytes, NULL);
I think the thread here is the same thing, but you've found it in
autofs...
https://lore.kernel.org/lkml/CAHk-=wgj=mken-efv5tkwjnehplg0dybq+r5zyguc4weunq...@mail.gmail.com/
--
Kees Cook
k:
https://lore.kernel.org/lkml/canpmjnowz5vpkqn+sywovtkfb4vst-rpwyenbmak0dlcpqs...@mail.gmail.com
Signed-off-by: Kees Cook
Acked-by: Vlastimil Babka
Link: https://lore.kernel.org/lkml/0f7dd7b2-7496-5e2d-9488-2ec9f8e90...@suse.cz/
---
mm/slub.c | 14 +++---
1 file changed, 3 insertions(+),
ther 2 can land. :)
Thanks!
-Kees
Kees Cook (3):
mm/slub: Clarify verification reporting
mm/slub: Fix redzoning for small allocations
mm/slub: Actually fix freelist pointer vs redzoning
Documentation/vm/slub.rst | 10 +-
mm/slub.c | 36 +++---
ere:
d86bd1bece6f ("mm/slub: support left redzone")
ffc79d288000 ("slub: use print_hex_dump")
2492268472e7 ("SLUB: change error reporting format to follow lockdep loosely")
Signed-off-by: Kees Cook
Acked-by: Vlastimil Babka
Link: https://lore.kernel.org/lkml/cfdb
being added for extra robustness, since it IS
possible to build kernels where this is allowed -- why keep foot-guns
around?)
(Note that no caches in this size range are known to exist in the kernel
currently.)
Fixes: 81819f0fc828 ("SLUB core")
Cc: sta...@vger.kernel.org
Signed-off-by:
On Wed, Oct 14, 2020 at 10:36:01PM -0400, Waiman Long wrote:
> On 10/8/20 7:34 PM, Kees Cook wrote:
> > It turns out that SLUB redzoning ("slub_debug=Z") checks from
> > s->object_size rather than from s->inuse (which is normally bumped to
> > make room
-by: Sami Tolvanen
> Reviewed-by: Kees Cook
> ---
> scripts/module.lds.S | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/scripts/module.lds.S b/scripts/module.lds.S
> index 69b9b71a6a47..037120173a22 100644
> --- a/scripts/module.lds.S
>
t; ...
>
> This change adds ANNOTATE_RETPOLINE_SAFE annotations to the jumps
> in assembly code to stop the warnings.
>
> Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
This looks like it's an independent fix -- can an x86 maintainer pick
up this patch directly?
--
Kees Cook
On Mon, Oct 12, 2020 at 05:31:45PM -0700, Sami Tolvanen wrote:
> This change removes all instances of DISABLE_LTO from
> Makefiles, as they are currently unused, and the preferred
> method of disabling LTO is to filter out the flags instead.
>
> Suggested-by: Kees Cook
> S
27;s happening here. But as it turns out, it's easier to do
this by employing both the process of elimination (mark the counters)
and direct identification (mark the refcount_t). Then the pool of
"unannotated" atomic_t instances continues to shrink.
--
Kees Cook
On Thu, Oct 15, 2020 at 09:25:26AM +1100, Stephen Rothwell wrote:
> Hi Kees,
>
> On Sun, 4 Oct 2020 19:44:52 -0700 Kees Cook wrote:
> >
> > On Sun, Oct 04, 2020 at 09:00:18PM +1100, Stephen Rothwell wrote:
> > > Hi Kees,
> > >
> > > On Sun, 4
On Sun, Oct 04, 2020 at 07:57:20PM -0700, Kees Cook wrote:
> Under some circumstances, the compiler generates .ctors.* sections. This
> is seen doing a cross compile of x86_64 from a powerpc64el host:
>
> x86_64-linux-gnu-ld: warning: orphan section `.ctors.65435' from
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
> Acked-by: Bjorn Helgaas
> Reviewed-by: Kees Cook
Another independent patch! :) Bjorn, since you've already
akes .mod files smaller and
> easier to read.
>
> Signed-off-by: Sami Tolvanen
> Reviewed-by: Kees Cook
Hi Masahiro,
This appears to be a general improvement as well. This looks like it can
land without depending on the rest of the series.
-Kees
> ---
> scripts/Makefil
stub with a stable name for each initcall to
> fix the issue when PREL32 relocations are used.
>
> Signed-off-by: Sami Tolvanen
> Reviewed-by: Kees Cook
This is another independent improvement... this could land before the
other portions of the series.
-Kees
> ---
&
On Sat, Oct 10, 2020 at 08:26:16AM -0500, YiFei Zhu wrote:
> 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
>
ibute to check_*() helpers (2020-10-12
15:19:07 -0700)
overflow update for v5.10-rc1
- Add __must_check to check_*_overflow() helpers
Kees Cook (1):
overflow
d clone3 selftests dependency) to
fix powerpc (Kees Cook, Thadeu Lima de Souza Cascardo)
- fix style issue in selftests (Zou Wei)
- upgrade "unknown action" from KILL_THREAD to KILL_PROCESS (Rich Felker)
- replace task_pt_regs(current) with current_pt_regs() (Denis Efremov)
- fix c
t need to be:
*(.ARM.exidx) *(.ARM.exidx.*)
*(.ARM.extab) *(.ARM.extab.*)
?
>
> > though I do see binutils linker scripts use precisely what you have.
> > So I guess that's fine.
> >
> > I guess we can't reuse `ARM_UNWIND_SECTIONS` since the ALIGN and
> > linker-script-defined-symbols would be weird in a DISCARD clause?
> >
> >
> > > + *(.ARM.extab*)
> > > #endif
> > > }
> > >
> > >
> > > base-commit: 6e0bf0e0e55000742a53c5f3b58f8669e0091a11
> > > --
> >
> >
> > --
> > Thanks,
> > ~Nick Desaulniers
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Clang Built Linux" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clang-built-linux+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/clang-built-linux/CAKwvOd%3D%2B98r6F4JjrPEoWX88WQ%3DB-KMRP2eWojabLk6it3i5KA%40mail.gmail.com.
>
>
>
> --
> 宋方睿
--
Kees Cook
On Mon, Oct 12, 2020 at 09:51:09PM +0100, Will Deacon wrote:
> On Mon, Oct 12, 2020 at 01:44:56PM -0700, Kees Cook wrote:
> > On Mon, Oct 12, 2020 at 09:31:16AM +0100, Will Deacon wrote:
> > > On Fri, Oct 09, 2020 at 09:13:34AM -0700, Sami Tolvanen wrote:
> > > &
On Mon, Oct 12, 2020 at 09:31:16AM +0100, Will Deacon wrote:
> On Fri, Oct 09, 2020 at 09:13:34AM -0700, Sami Tolvanen wrote:
> > Allow CONFIG_LTO_CLANG and CONFIG_THINLTO to be enabled.
> >
> > Signed-off-by: Sami Tolvanen
> > Reviewed-by: Kees Cook
> >
On Mon, Oct 12, 2020 at 08:01:04AM +, Christopher Lameter wrote:
> On Fri, 9 Oct 2020, Kees Cook wrote:
>
> > Store the freelist pointer out of line when object_size is smaller than
> > sizeof(void *) and redzoning is enabled.
> >
> > (Note that no caches with
? With some KUnit help? However, I am not
> sure about hard panics, they may not play well with unit-testing...
A lot of the behavioral tests in LKDTM end up triggering arch-specific
logging. I decided to avoid trying to consolidate it in favor of
actually getting the test coverage. :)
--
Kees Cook
ilters against @sd
> * @sd: optional seccomp data to be passed to filters
> @@ -320,6 +389,9 @@ static u32 seccomp_run_filters(const struct seccomp_data
> *sd,
> if (WARN_ON(f == NULL))
> return SECCOMP_RET_KILL_PROCESS;
>
> + if (seccomp_cache_check_allow(f, sd))
> + return SECCOMP_RET_ALLOW;
> +
> /*
>* All filters in the list are evaluated and the lowest BPF return
>* value always takes priority (ignoring the DATA).
> --
> 2.28.0
>
This is all looking good; thank you! I'm doing some test builds/runs
now. :)
--
Kees Cook
config
> +++ b/arch/x86/Kconfig
> @@ -150,6 +150,7 @@ config X86
> select HAVE_ARCH_COMPAT_MMAP_BASES if MMU && COMPAT
> select HAVE_ARCH_PREL32_RELOCATIONS
> select HAVE_ARCH_SECCOMP_FILTER
> + select HAVE_ARCH_SECCOMP_CACHE
> select HAVE_ARCH_THREAD_STRUCT_WHITELIST
> select HAVE_ARCH_STACKLEAK
> select HAVE_ARCH_TRACEHOOK
HAVE_ARCH_SECCOMP_CACHE isn't used any more. I think this was left over
from before.
--
Kees Cook
return false;
> > +
> > + insns = bpf_classic_proglen(fprog);
>
> bpf_classic_proglen() is defined as:
>
> #define bpf_classic_proglen(fprog) (fprog->len * sizeof(fprog->filter[0]))
>
> so this is wrong - what you want is the number of instructions in the
> program, what you actually have is the size of the program in bytes.
> Please instead check for `pc < fprog->len` in the loop condition.
Oh yes, good catch. I had this wrong in my v1.
--
Kees Cook
tomics, which means we have a much lower chance of
introducing new flaws (and maybe we'll fix flaws during the conversion,
which we've certainly seen before when doing this stricter type/language
changes).
I don't see why this is an objectionable goal.
--
Kees Cook
https://lore.kernel.org/linux-mm/20200807160627.ga1420...@elver.google.com/
Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location)
Tested-by: Marco Elver
Link:
https://lore.kernel.org/lkml/canpmjnowz5vpkqn+sywovtkfb4vst-rpwyenbmak0dlcpqs...@mail.gmail.com
Signed-off-by
t;SLUB core")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
mm/slub.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index f4f1d63f0ab9..752fad36522c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3682,15 +3682,17 @@ static int calculate_sizes
ce of such small-sized caches actually be used in the kernel, but
that's no reason to let the bugs continue to exist. :)
Thanks!
-Kees
Kees Cook (3):
mm/slub: Clarify verification reporting
mm/slub: Fix redzoning for small allocations
mm/slub: Actually fix freelist pointer vs redzoning
D
000 ("slub: use print_hex_dump")
Fixes: 2492268472e7 ("SLUB: change error reporting format to follow lockdep
loosely")
Signed-off-by: Kees Cook
---
Documentation/vm/slub.rst | 10 +-
mm/slub.c | 14 +++---
2 files changed, 12 insertions(+), 12 de
to take this through mine.
I'd mentioned this in the v2, but yes, please take via your trees. :)
I'm glad to see this landing!
--
Kees Cook
: Greg Kroah-Hartman
> Signed-off-by: Shuah Khan
Reviewed-by: Kees Cook
--
Kees Cook
overflows and undefined behavior when used to manage state
> changes and device usage/open states.
>
> Signed-off-by: Shuah Khan
Reviewed-by: Kees Cook
--
Kees Cook
with
> the atomic_t api, which it is built on top of.
>
> Using counter_atomic* to guard lifetimes could lead to use-after free
> when it overflows and undefined behavior when used to manage state
> changes and device usage/open states.
>
> Reviewed-by: Greg Kroah-Hartman
> Signed-off-by: Shuah Khan
Reviewed-by: Kees Cook
--
Kees Cook
rom an OR of some
> bits, and __is_defined(SECCOMP_ARCH_NATIVE) would not expand to
> __ARG_PLACEHOLDER_1 during any stage in the preprocessing.
>
> Is there any better way to do this? I'm thinking of just doing #if
> defined(CONFIG_CHECKPOINT_RESTORE) || defined(SECCOMP_ARCH_NATIVE)
> like in Kee's patch.
Yeah, I think that's simplest.
--
Kees Cook
On Thu, Oct 08, 2020 at 07:17:39PM -0500, YiFei Zhu wrote:
> 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 s
small-sized caches in the kernel
currently.)
Reported-by: Marco Elver
Link:
https://lore.kernel.org/linux-mm/20200807160627.ga1420...@elver.google.com/
Fixes: 89b83f282d8b (slub: avoid redzone when choosing freepointer location)
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook
---
mm/slub.c | 17 +
seems to be the culprit:
> >
> > commit 3202fa62fb43087387c65bfa9c100feffac74aa6
> > Author: Kees Cook
> > Date: Wed Apr 1 21:04:27 2020 -0700
> >
> > slub: relocate freelist pointer to middle of object
> >
> > Reverting this commit and one of it's
; numeric constant
>17 | #define P_ALL 0
> |^
>
> Signed-off-by: Tommi Rantala
Reviewed-by: Kees Cook
--
Kees Cook
On Thu, Oct 08, 2020 at 03:26:32PM +0300, Tommi Rantala wrote:
> XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
> into SKIP"), use SKIP instead.
>
> Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tom
On Thu, Oct 08, 2020 at 03:26:33PM +0300, Tommi Rantala wrote:
> XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
> into SKIP"), use SKIP instead.
>
> Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tom
On Thu, Oct 08, 2020 at 03:26:31PM +0300, Tommi Rantala wrote:
> XFAIL is gone since 9847d24af95c ("selftests/harness: Refactor XFAIL
> into SKIP"), use SKIP instead.
>
> Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tom
ks")
> Signed-off-by: Tommi Rantala
Reviewed-by: Kees Cook
--
Kees Cook
ot;selftests/harness: Refactor XFAIL into SKIP")
> Signed-off-by: Tommi Rantala
Nice catch!
Acked-by: Kees Cook
--
Kees Cook
1056d3d2c97e ("selftests: enforce local header dependency in lib.mk")
> Signed-off-by: Tommi Rantala
Ah yes, thanks!
Acked-by: Kees Cook
--
Kees Cook
inutes. Got it; thanks!
> IOW, I disagree with you, and think that counter_atomic_32 is more
> appropriate here than refcount_t.
I agree now! :)
--
Kees Cook
This silences a static checker warning due to the unusual macro
construction of EXPECT_*() by adding explicit {}s around the enclosing
while loop.
Reported-by: Dan Carpenter
Fixes: 7f657d5bf507 ("selftests: tls: add selftests for TLS sockets")
Signed-off-by: Kees Cook
---
v2: rebase t
On Wed, Oct 07, 2020 at 09:38:47PM +0200, Johannes Berg wrote:
> On Wed, 2020-10-07 at 13:33 -0600, Shuah Khan wrote:
> > On 10/7/20 12:15 PM, Kees Cook wrote:
> > > On Tue, Oct 06, 2020 at 02:44:35PM -0600, Shuah Khan wrote:
> > > > counter_atomic* is introduced to b
On Wed, Oct 07, 2020 at 01:26:53PM -0600, Shuah Khan wrote:
> On 10/7/20 12:11 PM, Kees Cook wrote:
> > My instinct is to say leave it "int" and adjust documentation, which is
> > the least disruptive, but I am enticed by the desire to make sure a
> > counter does
e
corrections to the generic read/write routines, I very specifically do
not want to rip out having a block device as a backing device, nor do I
want to revert the configuration management to being backing device
specific.
--
Kees Cook
e in the else block.
>
> Signed-off-by: Sudip Mukherjee
Reviewed-by: Kees Cook
--
Kees Cook
ramoops to pstore/zone,
etc, and remove all the ramoops-specific configuration which is common
to pstore/zone.
--
Kees Cook
? (Originally I thought this was going through Greg's tree since
it was touching a lot of drivers.)
--
Kees Cook
onvert them to use counter_atomic32.
>
> Overflow will wrap around and reset the counts as was the case prior to
> the conversion.
>
> Acked-by: Borislav Petkov
> Signed-off-by: Shuah Khan
Looks like pure logging. :)
Reviewed-by: Kees Cook
--
Kees Cook
vmci_guest_remove_device(struct pci_dev *pdev)
>
> dev_dbg(&pdev->dev, "Removing device\n");
>
> - atomic_dec(&vmci_num_guest_devices);
> + counter_atomic32_dec(&vmci_num_guest_devices);
If there is a bug elsewhere and vmci_guest_remove_device() (or probe)
gets called too many times, shouldn't we protect the rest of this stack
from having vmci_num_guest_devices go negative (and therefore non-zero)?
This really seems like it should be refcount_t to me, though I have no
idea what the races between the dec() and the read() might mean in this
code generally.
--
Kees Cook
et the stats and no change with the conversion.
>
> Convert them to use counter_atomic32.
>
> Reviewed-by: Corey Minyard
> Signed-off-by: Shuah Khan
Reviewed-by: Kees Cook
--
Kees Cook
_probe_init(void)
>* errors or warnings being reported by the probe routine.
>*/
> if (err)
> - atomic_inc(&errors);
> + counter_atomic32_inc(&errors);
> else
> err = -EINVAL;
>
> pr_err("Test failed with %d errors and %d warnings\n",
> -atomic_read(&errors), atomic_read(&warnings));
> +counter_atomic32_read(&errors),
> +counter_atomic32_read(&warnings));
>
> return err;
> }
> --
> 2.25.1
>
But yeah, this is otherwise just reporting and simple one-time synchronization.
Reviewed-by: Kees Cook
--
Kees Cook
version doesn't change the overflow wrap around behavior.
>
> Reviewed-by: Joel Fernandes (Google)
> Signed-off-by: Shuah Khan
Yup, seems to be stats-only.
Reviewed-by: Kees Cook
--
Kees Cook
cked-by: Rafael J. Wysocki
> Acked-by: Borislav Petkov
> Signed-off-by: Shuah Khan
Yup, also logging only, it seems.
Reviewed-by: Kees Cook
--
Kees Cook
ked-by: Rafael J. Wysocki
> Signed-off-by: Shuah Khan
Agreed: this looks like logging only.
Reviewed-by: Kees Cook
--
Kees Cook
Kroah-Hartman
> Signed-off-by: Shuah Khan
I actually wonder if this should use refcount_t just because it is
designed to be an alway-unique value. It is hard to imagine ever causing
this to overflow, but why not let it be protected?
--
Kees Cook
> meets the other criteria to be converted. Convert it to use
> counter_atomic32.
>
> Reviewed-by: Greg Kroah-Hartman
> Signed-off-by: Shuah Khan
With the "wrap around to 0" commit log detail fixed, look good:
Reviewed-by: Kees Cook
--
Kees Cook
to guard lifetimes could lead to use-after free
> when it overflows and undefined behavior when used to manage state
> changes and device usage/open states.
>
> Signed-off-by: Shuah Khan
Reviewed-by: Kees Cook
--
Kees Cook
;
> +
> + start_val = counter_atomic32_read(&ucnt);
> + counter_atomic32_dec(&ucnt);
> + end_val = counter_atomic32_read(&ucnt);
This is testing that counter operations match native int operations,
which seems fine. I wonder if hard-coded values should be added too, to
just more directly map the explicit expectations? E.g. adding a second
test with each:
test_counter_result_print32("Test underflow (int)",
start_val, end_val, start_val-1);
test_counter_result_print32("Test underflow (-1)",
start_val, end_val, -1);
> +
> + start_val = counter_atomic32_read(&ocnt);
> + end_val = counter_atomic32_inc_return(&ocnt);
and:
test_counter_result_print32("Test overflow (int)",
start_val, end_val, start_val+1);
test_counter_result_print32("Test underflow (INT_MIN)",
start_val, end_val, INT_MIN);
Otherwise, yes, looks great; thank you!
--
Kees Cook
r.
>
> Done with cocci scripts and some typing.
Can you include the cocci script in the commit log? It might be nicer to
split the "manual" changes from the cocci changes, as that makes review
much easier too.
Regardless, yes, I'm a fan of switching these all around to
sysfs_emit*(). :)
Thanks!
--
Kees Cook
nux/pstore_blk.h
index 61e914522b01..2bf07d20ce43 100644
--- a/include/linux/pstore_blk.h
+++ b/include/linux/pstore_blk.h
@@ -46,9 +46,6 @@ struct pstore_blk_info {
sector_t start_sect;
};
-int register_pstore_blk(struct pstore_blk_info *info);
-void unregister_pstore_blk(unsigned int maj
the security_list_options union. Fix
> the type in the LSM_HOOK macro as 'enum kernel_load_data_id' is what is
> expected.
>
> Fixes: b64fcae74b6d ("LSM: Introduce kernel_post_load_data() hook")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1172
> Sig
On Sun, Oct 04, 2020 at 12:16:14AM -0700, Nathan Chancellor wrote:
> On Fri, Oct 02, 2020 at 03:15:26PM -0700, Kees Cook wrote:
> > Clang handles 'maybe-uninitialized' better in the face of using UBSAN,
> > so do not make this universally disabled for UBSAN builds.
>
On Sun, Oct 04, 2020 at 12:08:47AM -0700, Nathan Chancellor wrote:
> On Fri, Oct 02, 2020 at 03:15:24PM -0700, Kees Cook wrote:
> > Instead of doing if/endif blocks with cc-option calls in the UBSAN
> > Makefile, move all the tests into Kconfig and use the Makefile to
> >
On Tue, Oct 06, 2020 at 04:28:09AM +0200, Willy Tarreau wrote:
> Hi Kees,
>
> On Mon, Oct 05, 2020 at 07:12:29PM -0700, Kees Cook wrote:
> > On Fri, Oct 02, 2020 at 05:16:11PM +0200, Thibaut Sautereau wrote:
> > > From: Thibaut Sautereau
> > >
> > >
Emese Revfy
> Signed-off-by: Thibaut Sautereau
Yes, that looks correct. Thank you!
Acked-by: Kees Cook
I'm not sure the best tree for this. Ted, Andrew, Linus? I'll take it
via my gcc plugin tree if no one else takes it. :)
--
Kees Cook
ssociated with them. Having implicit kmem caches based on the type
being allocated there would need some pretty extensive plumbing, I
think?
--
Kees Cook
MAINTAINERS file and the .mailmap to accomplish this, so that
linux-hardening@ can be treated like any other regular upstream kernel
development list.
Link: https://lore.kernel.org/linux-hardening/202010051443.279CC265D@keescook/
Signed-off-by: Kees Cook
---
.mailmap| 1 +
MAINTAINERS | 4 +
On Mon, Oct 05, 2020 at 04:19:49PM -0700, Randy Dunlap wrote:
> On 10/5/20 3:53 PM, Kees Cook wrote:
> > As more email from git history gets aimed at the OpenWall
> > kernel-hardening@ list, there has been a desire to separate "new topics"
> > from "on-going&qu
Project/Get_Involved
Signed-off-by: Kees Cook
---
I intend to include this in one of my trees, unless akpm or jon want it?
---
.mailmap| 1 +
MAINTAINERS | 4 ++--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/.mailmap b/.mailmap
index 50096b96c85d..91cea2d9a6a3 100644
--- a/.ma
gt; [...]
Applied, thanks!
I added the stable CC, but I'd agree: it's not so urgent that I need to
get this into Linus's tree ahead of the regular merge window. :)
[1/1] seccomp: Make duplicate listener detection non-racy
https://git.kernel.org/kees/c/ed2d479d3335
--
Kees Cook
proc_skip_char(&p, &left, '\n');
> }
> left += skipped;
> --
> 2.11.0
>
--
Kees Cook
kernel.org/lkml/202009181443.C2179FB@keescook/
Fixes: 36e2c7421f02 ("fs: don't allow splice read/write without explicit ops")
Signed-off-by: Kees Cook
---
.../selftests/splice/short_splice_read.sh | 119 ++
1 file changed, 98 insertions(+), 21 deletions(-)
diff -
orphans along with the regular .ctors section.
Reported-by: Stephen Rothwell
Tested-by: Stephen Rothwell
Fixes: 83109d5d5fba ("x86/build: Warn on orphan section placement")
Signed-off-by: Kees Cook
---
v2: brown paper bag version: fix whitespace for proper backslash alignment
---
inc
orphans along with the regular .ctors section.
Reported-by: Stephen Rothwell
Link: https://lore.kernel.org/lkml/20200914132249.40c88...@canb.auug.org.au
Tested-by: Stephen Rothwell
Link: https://lore.kernel.org/lkml/20201004210018.5bbc6...@canb.auug.org.au
Fixes: 83109d5d5fba ("x86/build: Warn
601 - 700 of 4885 matches
Mail list logo
