Re: [PATCH RFC v2 0/6] Break heap spraying needed for exploiting use-after-free

It will reuse the memory for other things when the whole slab is freed though. Not really realistic to change that without it being backed by virtual memory along with higher-level management of regions to avoid intense fragmentation and metadata waste. It would depend a lot on having much

Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

Yeah, a no-op pkey_alloc flag tied to this patch to provide a way to detect if pkey state is preserved on fork, since kernels without the patch would report EINVAL. Something like PKEY_ASSERT_FORK_INHERIT_STATE would make sense. Otherwise, it's going to be quite painful to adopt this in userspace

Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

Yeah, a no-op pkey_alloc flag tied to this patch to provide a way to detect if pkey state is preserved on fork, since kernels without the patch would report EINVAL. Something like PKEY_ASSERT_FORK_INHERIT_STATE would make sense. Otherwise, it's going to be quite painful to adopt this in userspace

Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

On Fri, 26 Oct 2018 at 18:12, Andy Lutomirski wrote: > > > > > On Oct 26, 2018, at 2:39 PM, Daniel Micay wrote: > > > > I ended up working around this with a pthread_atfork handler disabling > > my usage of the feature in the child process for the time be

Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

On Fri, 26 Oct 2018 at 18:12, Andy Lutomirski wrote: > > > > > On Oct 26, 2018, at 2:39 PM, Daniel Micay wrote: > > > > I ended up working around this with a pthread_atfork handler disabling > > my usage of the feature in the child process for the time be

Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

I ended up working around this with a pthread_atfork handler disabling my usage of the feature in the child process for the time being. I don't have an easy way to detect if the bug is present within a library so I'm going to need a kernel version check with a table of kernel releases fixing the

Re: [PATCH 1/2] x86/pkeys: copy pkey state at fork()

I ended up working around this with a pthread_atfork handler disabling my usage of the feature in the child process for the time being. I don't have an easy way to detect if the bug is present within a library so I'm going to need a kernel version check with a table of kernel releases fixing the

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

Well, that's not related, it's just this: #ifdef __GNUC__ #if (__GNUC__ == 3 && __GNUC_MINOR__ < 3) #error Your compiler is too buggy; it is known to miscompile kernels. #errorKnown good compilers: 3.3, 4.x #endif #if GCC_VERSION >= 40800 && GCC_VERSION < 40803 #error Your compiler is too

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

Well, that's not related, it's just this: #ifdef __GNUC__ #if (__GNUC__ == 3 && __GNUC_MINOR__ < 3) #error Your compiler is too buggy; it is known to miscompile kernels. #errorKnown good compilers: 3.3, 4.x #endif #if GCC_VERSION >= 40800 && GCC_VERSION < 40803 #error Your compiler is too

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

On 20 April 2018 at 15:15, Pavel Machek wrote: > Hi! > >> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to >> >> a particular subset of arm architectures? (My local builds of arm all >> >> succeed, for example. Can you send your failing config?) I'll take a

Re: [regression v4.17-rc0] Re: FORTIFY_SOURCE breaks ARM compilation in -next -- was Re: ARM compile failure in Re: linux-next: Tree for Apr 4

On 20 April 2018 at 15:15, Pavel Machek wrote: > Hi! > >> >> Hi! Sorry I lost this email in my inbox. It seems this is specific to >> >> a particular subset of arm architectures? (My local builds of arm all >> >> succeed, for example. Can you send your failing config?) I'll take a >> >> closer

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> I don't think the difference between C and C++ const pointer > conversions I mean I don't think the difference between them was intended.

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> I don't think the difference between C and C++ const pointer > conversions I mean I don't think the difference between them was intended.

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

No, it's undefined behavior to write to a const variable. The `static` and `const` on the variable both change the code generation in the real world as permitted / encouraged by the standard. It's placed in read-only memory. Trying to write to it will break. It's not "implemented defined" to write

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

No, it's undefined behavior to write to a const variable. The `static` and `const` on the variable both change the code generation in the real world as permitted / encouraged by the standard. It's placed in read-only memory. Trying to write to it will break. It's not "implemented defined" to write

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > not really going to show a lot of variation. This array will always have the > same size on the stack. The issue is that unlike in C++, a `static const` can't be used in a constant expression in C. It's unclear why C

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> Just wondering. Is this actually a VLA. FFT_NUM_SAMPLES was static const so > not really going to show a lot of variation. This array will always have the > same size on the stack. The issue is that unlike in C++, a `static const` can't be used in a constant expression in C. It's unclear why C

Re: VLA removal (was Re: [RFC 2/2] lustre: use VLA_SAFE)

On 7 March 2018 at 13:09, Linus Torvalds wrote: > On Wed, Mar 7, 2018 at 9:37 AM, Kees Cook wrote: >> >> Building with -Wvla, I see 209 unique locations reported in 60 directories: >> http://paste.ubuntu.com/p/srQxwPQS9s/ > > Ok, that's not

Re: VLA removal (was Re: [RFC 2/2] lustre: use VLA_SAFE)

On 7 March 2018 at 13:09, Linus Torvalds wrote: > On Wed, Mar 7, 2018 at 9:37 AM, Kees Cook wrote: >> >> Building with -Wvla, I see 209 unique locations reported in 60 directories: >> http://paste.ubuntu.com/p/srQxwPQS9s/ > > Ok, that's not so bad. Maybe Greg could even add it to one of those >

Re: [RFC PATCH] Randomization of address chosen by mmap.

On 5 March 2018 at 08:09, Ilya Smith wrote: > >> On 4 Mar 2018, at 23:56, Matthew Wilcox wrote: >> Thinking about this more ... >> >> - When you call munmap, if you pass in the same (addr, length) that were >> used for mmap, then it should unmap the

Re: [RFC PATCH] Randomization of address chosen by mmap.

On 5 March 2018 at 08:09, Ilya Smith wrote: > >> On 4 Mar 2018, at 23:56, Matthew Wilcox wrote: >> Thinking about this more ... >> >> - When you call munmap, if you pass in the same (addr, length) that were >> used for mmap, then it should unmap the guard pages as well (that >> wasn't part

Re: [RFC PATCH] Randomization of address chosen by mmap.

On 3 March 2018 at 08:58, Ilya Smith <blackz...@gmail.com> wrote: > Hello Daniel, thanks for sharing you experience! > >> On 1 Mar 2018, at 00:02, Daniel Micay <danielmi...@gmail.com> wrote: >> >> I don't think it makes sense for the kernel to attempt mitigation

Re: [RFC PATCH] Randomization of address chosen by mmap.

On 3 March 2018 at 08:58, Ilya Smith wrote: > Hello Daniel, thanks for sharing you experience! > >> On 1 Mar 2018, at 00:02, Daniel Micay wrote: >> >> I don't think it makes sense for the kernel to attempt mitigations to >> hide libraries. The best way to do t

Re: [RFC PATCH] Randomization of address chosen by mmap.

The option to add at least one guard page would be useful whether or not it's tied to randomization. It's not feasible to do that in userspace for mmap as a whole, only specific users of mmap like malloc and it adds significant overhead vs. a kernel implementation. It could optionally let you

Re: [RFC PATCH] Randomization of address chosen by mmap.

The option to add at least one guard page would be useful whether or not it's tied to randomization. It's not feasible to do that in userspace for mmap as a whole, only specific users of mmap like malloc and it adds significant overhead vs. a kernel implementation. It could optionally let you

Re: [RFC] Warn the user when they could overflow mapcount

I think there are likely legitimate programs mapping something a bunch of times. Falling back to a global object -> count mapping (an rbtree / radix trie or whatever) with a lock once it hits saturation wouldn't risk breaking something. It would permanently leave the inline count saturated and

Re: [RFC] Warn the user when they could overflow mapcount

I think there are likely legitimate programs mapping something a bunch of times. Falling back to a global object -> count mapping (an rbtree / radix trie or whatever) with a lock once it hits saturation wouldn't risk breaking something. It would permanently leave the inline count saturated and

Re: [RFC] Warn the user when they could overflow mapcount

I guess it could saturate and then switch to tracking the count via an object pointer -> count mapping with a global lock? Whatever the solution is should probably be a generic one since it's a recurring issue.

Re: [RFC] Warn the user when they could overflow mapcount

I guess it could saturate and then switch to tracking the count via an object pointer -> count mapping with a global lock? Whatever the solution is should probably be a generic one since it's a recurring issue.

Re: [RFC] Warn the user when they could overflow mapcount

I don't think the kernel can get away with the current approach. Object sizes and counts on 64-bit should be 64-bit unless there's a verifiable reason they can get away with 32-bit. Having it use leak memory isn't okay, just much less bad than vulnerabilities exploitable beyond just denial of

Re: [RFC] Warn the user when they could overflow mapcount

I don't think the kernel can get away with the current approach. Object sizes and counts on 64-bit should be 64-bit unless there's a verifiable reason they can get away with 32-bit. Having it use leak memory isn't okay, just much less bad than vulnerabilities exploitable beyond just denial of

Re: [RFC] Warn the user when they could overflow mapcount

>> That seems pretty bad. So here's a patch which adds documentation to the >> two sysctls that a sysadmin could use to shoot themselves in the foot, >> and adds a warning if they change either of them to a dangerous value. > > I have negative feelings about this patch, mostly because AFAICS: > >

Re: [RFC] Warn the user when they could overflow mapcount

>> That seems pretty bad. So here's a patch which adds documentation to the >> two sysctls that a sysadmin could use to shoot themselves in the foot, >> and adds a warning if they change either of them to a dangerous value. > > I have negative feelings about this patch, mostly because AFAICS: > >

Re: [kernel-hardening] Re: [PATCHv2 5/7] printk: allow kmsg to be encrypted using public key encryption

> Do you have any backing from makers of such devices? I'd like to hear > from Google's Android team or whoever that would turn this feature on. (I'm not a Google employee, but I work on Android security and contribute some of that to AOSP.) Android restricts access to dmesg with SELinux, so

Re: [kernel-hardening] Re: [PATCHv2 5/7] printk: allow kmsg to be encrypted using public key encryption

> Do you have any backing from makers of such devices? I'd like to hear > from Google's Android team or whoever that would turn this feature on. (I'm not a Google employee, but I work on Android security and contribute some of that to AOSP.) Android restricts access to dmesg with SELinux, so

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

Harouni wrote: > On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay <danielmi...@gmail.com> > wrote: > [...] > > Lots of potential module attack surface also gets eliminated by > > default > > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > > comm

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

Harouni wrote: > On Thu, Nov 30, 2017 at 7:51 AM, Daniel Micay > wrote: > [...] > > Lots of potential module attack surface also gets eliminated by > > default > > via their SELinux whitelists for /dev, /sys, /proc, debugfs, ioctl > > commands, etc. The global se

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> And once you disable it by default, and it becomes purely opt-in, that > means that nothing will change for most cases. Some embedded people > that do their own thing (ie Android) might change, but normal > distributions probably won't. > > Yes, Android may be 99% of the users, and yes, the

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

> And once you disable it by default, and it becomes purely opt-in, that > means that nothing will change for most cases. Some embedded people > that do their own thing (ie Android) might change, but normal > distributions probably won't. > > Yes, Android may be 99% of the users, and yes, the

Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

On Mon, 2017-11-06 at 16:14 -0600, Serge E. Hallyn wrote: > Quoting Daniel Micay (danielmi...@gmail.com): > > Substantial added attack surface will never go away as a problem. > > There > > aren't a finite number of vulnerabilities to be found. > > There's varying level

Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

On Mon, 2017-11-06 at 16:14 -0600, Serge E. Hallyn wrote: > Quoting Daniel Micay (danielmi...@gmail.com): > > Substantial added attack surface will never go away as a problem. > > There > > aren't a finite number of vulnerabilities to be found. > > There's varying level

Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

Substantial added attack surface will never go away as a problem. There aren't a finite number of vulnerabilities to be found.

Re: [kernel-hardening] Re: [PATCH resend 2/2] userns: control capabilities of some user namespaces

Substantial added attack surface will never go away as a problem. There aren't a finite number of vulnerabilities to be found.

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

> Brad trolls us all lightly with this trivia question: > > https://twitter.com/grsecurity/status/905246423591084033 I'll respond to your proposed scenario rather than guessing at what is being suggested there and if it's actually the same thing as what you've brought up. They've stated many

Re: [kernel-hardening] [PATCH v2 0/5] stackprotector: ascii armor the stack canary

> Brad trolls us all lightly with this trivia question: > > https://twitter.com/grsecurity/status/905246423591084033 I'll respond to your proposed scenario rather than guessing at what is being suggested there and if it's actually the same thing as what you've brought up. They've stated many

Re: nios2 crash due to 'init/main.c: extract early boot entropy from the passed cmdline'

On Mon, 2017-09-11 at 10:35 -0700, Guenter Roeck wrote: > On Mon, Sep 11, 2017 at 09:36:00AM -0700, Kees Cook wrote: > > On Sat, Sep 9, 2017 at 8:58 PM, Guenter Roeck > > wrote: > > > Hi, > > > > > > I noticed that nios2 images crash in mainline. Bisect points to > > > commit

Re: nios2 crash due to 'init/main.c: extract early boot entropy from the passed cmdline'

On Mon, 2017-09-11 at 10:35 -0700, Guenter Roeck wrote: > On Mon, Sep 11, 2017 at 09:36:00AM -0700, Kees Cook wrote: > > On Sat, Sep 9, 2017 at 8:58 PM, Guenter Roeck > > wrote: > > > Hi, > > > > > > I noticed that nios2 images crash in mainline. Bisect points to > > > commit > > > 33d72f3822d7

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

> I did say 'external attacker' but it could be made clearer. Er, s/say/mean to imply/ I do think it will have some local value after Android 8 which should start shipping in a few days though. I'll look into having the kernel stash some entropy in pstore soon since that seems like it could be

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

> I did say 'external attacker' but it could be made clearer. Er, s/say/mean to imply/ I do think it will have some local value after Android 8 which should start shipping in a few days though. I'll look into having the kernel stash some entropy in pstore soon since that seems like it could be

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote: > On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich <n...@google.com> > wrote: > > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott <labb...@redhat.com> > > wrote: > > > From: Daniel Micay <danielmi..

Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote: > On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich > wrote: > > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott > > wrote: > > > From: Daniel Micay > > > > > > Existing Android bootloaders us

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, 2017-08-16 at 23:31 -0400, Theodore Ts'o wrote: > On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote: > > From: Daniel Micay <danielmi...@gmail.com> > > > > Existing Android bootloaders usually pass data useful as early > > entropy > >

Re: [PATCHv3 2/2] extract early boot entropy from the passed cmdline

On Wed, 2017-08-16 at 23:31 -0400, Theodore Ts'o wrote: > On Wed, Aug 16, 2017 at 04:14:58PM -0700, Laura Abbott wrote: > > From: Daniel Micay > > > > Existing Android bootloaders usually pass data useful as early > > entropy > > on the kernel command-line.

Re: drivers/tty/serial/8250/8250_fintek.c:364: warning: 'probe_data' is used uninitialized in this function

On Wed, 2017-08-09 at 17:32 +0200, Arnd Bergmann wrote: > On Wed, Aug 9, 2017 at 5:07 PM, kbuild test robot > wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin > > ux.git master > > head: bfa738cf3dfae2111626650f86135f93c5ff0a22 > > commit:

Re: drivers/tty/serial/8250/8250_fintek.c:364: warning: 'probe_data' is used uninitialized in this function

On Wed, 2017-08-09 at 17:32 +0200, Arnd Bergmann wrote: > On Wed, Aug 9, 2017 at 5:07 PM, kbuild test robot > wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin > > ux.git master > > head: bfa738cf3dfae2111626650f86135f93c5ff0a22 > > commit:

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 14:18 -0700, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook > > wrote: > > > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann > > > wrote: > > > >

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 14:18 -0700, Kees Cook wrote: > On Mon, Jul 31, 2017 at 2:10 PM, Arnd Bergmann wrote: > > On Mon, Jul 31, 2017 at 10:58 PM, Kees Cook > > wrote: > > > On Mon, Jul 31, 2017 at 12:30 AM, Arnd Bergmann > > > wrote: > > > > On Mon, Jul 31, 2017 at 9:08 AM, Moni Shoua > > > >

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 21:19 +0200, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 6:17 PM, Bart Van Assche om> wrote: > > On Mon, 2017-07-31 at 18:04 +0200, Arnd Bergmann wrote: > > > On Mon, Jul 31, 2017 at 5:32 PM, Bart Van Assche > > dc.com> wrote: >

Re: [PATCH] infiniband: avoid overflow warning

On Mon, 2017-07-31 at 21:19 +0200, Arnd Bergmann wrote: > On Mon, Jul 31, 2017 at 6:17 PM, Bart Van Assche om> wrote: > > On Mon, 2017-07-31 at 18:04 +0200, Arnd Bergmann wrote: > > > On Mon, Jul 31, 2017 at 5:32 PM, Bart Van Assche > > dc.com> wrote: > > > > So inetaddr_event() assigns AF_INET

Re: [PATCH] fortify: Use WARN instead of BUG for now

I think the 'else' added in the proposed patch makes it too complicated for GCC to optimize out the __attribute__((error)) checks before they're considered to be errors. It's not needed so it's probably best to just avoid doing something like that. The runtime checks can't get false positives from

Re: [PATCH] fortify: Use WARN instead of BUG for now

I think the 'else' added in the proposed patch makes it too complicated for GCC to optimize out the __attribute__((error)) checks before they're considered to be errors. It's not needed so it's probably best to just avoid doing something like that. The runtime checks can't get false positives from

Re: [PATCH] fortify: Use WARN instead of BUG for now

> Maybe we could do two phases? One to s/BUG/WARN/ and the second to > improve the message? s/fortify_panic/fortify_overflow/ + use WARN + remove __noreturn makes sense as one commit. Still think the *option* of __noreturn + BUG should be kept there even just for measuring the size overhead.

Re: [PATCH] fortify: Use WARN instead of BUG for now

> Maybe we could do two phases? One to s/BUG/WARN/ and the second to > improve the message? s/fortify_panic/fortify_overflow/ + use WARN + remove __noreturn makes sense as one commit. Still think the *option* of __noreturn + BUG should be kept there even just for measuring the size overhead.

Re: [PATCH] fortify: Use WARN instead of BUG for now

It should just be renamed from fortify_panic -> fortify_error, including in arch/x86/boot/compressed/misc.c and arch/x86/boot/compressed/misc.c. It can use WARN instead of BUG by with a 'default n', !COMPILE_TEST option to use BUG again. Otherwise it needs to be patched downstream when that's

Re: [PATCH] fortify: Use WARN instead of BUG for now

It should just be renamed from fortify_panic -> fortify_error, including in arch/x86/boot/compressed/misc.c and arch/x86/boot/compressed/misc.c. It can use WARN instead of BUG by with a 'default n', !COMPILE_TEST option to use BUG again. Otherwise it needs to be patched downstream when that's

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

It was known that there are going to be bugs to work through, many of them relatively benign like the leaks of data near string constants (probably other string constants) in rodata. It makes sense to have it default to WARN with BUG / noreturn as a non-default configuration option for it, I guess

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

It was known that there are going to be bugs to work through, many of them relatively benign like the leaks of data near string constants (probably other string constants) in rodata. It makes sense to have it default to WARN with BUG / noreturn as a non-default configuration option for it, I guess

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> So the fortify_string code has decided that only a single-byte (or > empty) memcpy is ok. > > And that, in turn, seems to be because we're copying from > optprobe_template_entry, which is declared as > > extern __visible kprobe_opcode_t optprobe_template_entry; > > so the fortify code

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

Re: [lkp-robot] [include/linux/string.h] 6974f0c455: kernel_BUG_at_lib/string.c

> [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 > [8.134886] arch_prepare_optimized_kprobe+0xd5/0x171 Probably this: /* Copy arch-dep-instance from template */ memcpy(buf, _template_entry, TMPL_END_IDX); Not a real bug, just technically undefined because these

Re: [PATCH] replace incorrect strscpy use in FORTIFY_SOURCE

On Fri, 2017-07-14 at 16:51 -0700, Kees Cook wrote: > On Fri, Jul 14, 2017 at 2:28 PM, Daniel Micay <danielmi...@gmail.com> > wrote: > > Using strscpy was wrong because FORTIFY_SOURCE is passing the > > maximum > > possible size of the outermost object, but strscpy d

Re: [PATCH] replace incorrect strscpy use in FORTIFY_SOURCE

On Fri, 2017-07-14 at 16:51 -0700, Kees Cook wrote: > On Fri, Jul 14, 2017 at 2:28 PM, Daniel Micay > wrote: > > Using strscpy was wrong because FORTIFY_SOURCE is passing the > > maximum > > possible size of the outermost object, but strscpy defines the count > >

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> I find "hardening" code that adds bugs to be particularly bad and > ugly, the same way that I absolutely *hate* debugging code that turns > out to make debugging impossible (we had that with the "better" stack > tracing code that caused kernel panics to kill the machine entirely > rather than

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> I find "hardening" code that adds bugs to be particularly bad and > ugly, the same way that I absolutely *hate* debugging code that turns > out to make debugging impossible (we had that with the "better" stack > tracing code that caused kernel panics to kill the machine entirely > rather than

[PATCH] replace incorrect strscpy use in FORTIFY_SOURCE

, 1) for intra-object overflow checks since it's the maximum possible size of the specified object with no guarantee of it being that large. Reuse of the fortified functions like this currently makes the runtime error reporting less precise but that can be improved later on. Signed-off-by: Daniel

[PATCH] replace incorrect strscpy use in FORTIFY_SOURCE

, 1) for intra-object overflow checks since it's the maximum possible size of the specified object with no guarantee of it being that large. Reuse of the fortified functions like this currently makes the runtime error reporting less precise but that can be improved later on. Signed-off-by: Daniel

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> The reason q_size isn't used is because it doesn't yet prevent read > overflow. The commit message mentions that among the current > limitations > along with __builtin_object_size(ptr, 1). Er rather, in strlcat, the q_size is unused after the fast path is because strnlen obtains the constant

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> The reason q_size isn't used is because it doesn't yet prevent read > overflow. The commit message mentions that among the current > limitations > along with __builtin_object_size(ptr, 1). Er rather, in strlcat, the q_size is unused after the fast path is because strnlen obtains the constant

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On Fri, 2017-07-14 at 13:50 -0700, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 1:38 PM, Daniel Micay <danielmi...@gmail.com> > wrote: > > > > If strscpy treats the count parameter as a *guarantee* of the dest > > size > > rather than a limit, > > No

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On Fri, 2017-07-14 at 13:50 -0700, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 1:38 PM, Daniel Micay > wrote: > > > > If strscpy treats the count parameter as a *guarantee* of the dest > > size > > rather than a limit, > > No, it's a *limit*. >

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> My initial patch used strlcpy there, because I wasn't aware of strscpy > before it was suggested: > > http://www.openwall.com/lists/kernel-hardening/2017/05/04/11 > > I was wrong to move it to strscpy. It could be switched back to > strlcpy > again unless the kernel considers the count

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

> My initial patch used strlcpy there, because I wasn't aware of strscpy > before it was suggested: > > http://www.openwall.com/lists/kernel-hardening/2017/05/04/11 > > I was wrong to move it to strscpy. It could be switched back to > strlcpy > again unless the kernel considers the count

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On Fri, 2017-07-14 at 12:58 -0700, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 12:43 PM, Andrey Ryabinin > wrote: > > > > > yet when I look at the generated code for __ip_map_lookup, I see > > > > > >movl$32, %edx #, > > >movq%r13, %rsi

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

On Fri, 2017-07-14 at 12:58 -0700, Linus Torvalds wrote: > On Fri, Jul 14, 2017 at 12:43 PM, Andrey Ryabinin > wrote: > > > > > yet when I look at the generated code for __ip_map_lookup, I see > > > > > >movl$32, %edx #, > > >movq%r13, %rsi # class, > > >

Re: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct

Re: [kernel-hardening] Re: [PATCH v3] mm: Add SLUB free list pointer obfuscation

On Thu, 2017-07-06 at 10:55 -0500, Christoph Lameter wrote: > On Thu, 6 Jul 2017, Kees Cook wrote: > > > On Thu, Jul 6, 2017 at 6:43 AM, Christoph Lameter > > wrote: > > > On Wed, 5 Jul 2017, Kees Cook wrote: > > > > > > > @@ -3536,6 +3565,9 @@ static int kmem_cache_open(struct > > > >

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

On Tue, 2017-06-27 at 12:34 -0700, Kees Cook wrote: > On Tue, Jun 27, 2017 at 12:26 PM, Jason A. Donenfeld > wrote: > > On Tue, Jun 27, 2017 at 9:22 PM, Andi Kleen > > wrote: > > > Who would actually set mman_min_addr incorrectly? > > > > Historically

Re: [PATCH v2] kref: Avoid null pointer dereference after WARN

On Tue, 2017-06-27 at 12:34 -0700, Kees Cook wrote: > On Tue, Jun 27, 2017 at 12:26 PM, Jason A. Donenfeld > wrote: > > On Tue, Jun 27, 2017 at 9:22 PM, Andi Kleen > > wrote: > > > Who would actually set mman_min_addr incorrectly? > > > > Historically there have been quite a few bypasses of

Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Tue, 2017-06-27 at 16:49 +0200, Michal Hocko wrote: > On Wed 21-06-17 10:32:01, Kees Cook wrote: > > The ELF_ET_DYN_BASE position was originally intended to keep loaders > > away from ET_EXEC binaries. (For example, running "/lib/ld- > > linux.so.2 > > /bin/cat" might cause the subsequent load

Re: [PATCH v2] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Tue, 2017-06-27 at 16:49 +0200, Michal Hocko wrote: > On Wed 21-06-17 10:32:01, Kees Cook wrote: > > The ELF_ET_DYN_BASE position was originally intended to keep loaders > > away from ET_EXEC binaries. (For example, running "/lib/ld- > > linux.so.2 > > /bin/cat" might cause the subsequent load

Re: [kernel-hardening] non-x86 per-task stack canaries

On Mon, 2017-06-26 at 14:04 -0700, Kees Cook wrote: > Hi, > > The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the > percpu area) for __stack_chk_guard, and all other architectures use a > global variable instead. This means we never change the stack canary > on non-x86

Re: [kernel-hardening] non-x86 per-task stack canaries

On Mon, 2017-06-26 at 14:04 -0700, Kees Cook wrote: > Hi, > > The stack protector functionality on x86_64 uses %gs:0x28 (%gs is the > percpu area) for __stack_chk_guard, and all other architectures use a > global variable instead. This means we never change the stack canary > on non-x86

Re: [kernel-hardening] [PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:28 -0700, Kees Cook wrote: > On Wed, Jun 21, 2017 at 10:27 AM, Daniel Micay <danielmi...@gmail.com> > wrote: > > On Wed, 2017-06-21 at 10:23 -0700, Kees Cook wrote: > > > On Wed, Jun 21, 2017 at 5:07 AM, Rik van Riel <r...@redhat.com> >

Re: [kernel-hardening] [PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:28 -0700, Kees Cook wrote: > On Wed, Jun 21, 2017 at 10:27 AM, Daniel Micay > wrote: > > On Wed, 2017-06-21 at 10:23 -0700, Kees Cook wrote: > > > On Wed, Jun 21, 2017 at 5:07 AM, Rik van Riel > > > wrote: > > > > On Tue,

Re: [kernel-hardening] [PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:23 -0700, Kees Cook wrote: > On Wed, Jun 21, 2017 at 5:07 AM, Rik van Riel wrote: > > On Tue, 2017-06-20 at 22:58 -0700, Kees Cook wrote: > > > +/* This is the base location for PIE (ET_DYN with INTERP) loads. > > > */ > > > +#define ELF_ET_DYN_BASE

Re: [kernel-hardening] [PATCH] [RFC] binfmt_elf: Use ELF_ET_DYN_BASE only for PIE

On Wed, 2017-06-21 at 10:23 -0700, Kees Cook wrote: > On Wed, Jun 21, 2017 at 5:07 AM, Rik van Riel wrote: > > On Tue, 2017-06-20 at 22:58 -0700, Kees Cook wrote: > > > +/* This is the base location for PIE (ET_DYN with INTERP) loads. > > > */ > > > +#define ELF_ET_DYN_BASE

Re: [kernel-hardening] [PATCH 23/23] mm: Allow slab_nomerge to be set at build time

On Mon, 2017-06-19 at 16:36 -0700, Kees Cook wrote: > Some hardened environments want to build kernels with slab_nomerge > already set (so that they do not depend on remembering to set the > kernel > command line option). This is desired to reduce the risk of kernel > heap > overflows being able

Re: [kernel-hardening] [PATCH 23/23] mm: Allow slab_nomerge to be set at build time

On Mon, 2017-06-19 at 16:36 -0700, Kees Cook wrote: > Some hardened environments want to build kernels with slab_nomerge > already set (so that they do not depend on remembering to set the > kernel > command line option). This is desired to reduce the risk of kernel > heap > overflows being able

[PATCH v5] add the option of fortified string.h functions

approach to avoid likely compatibility issues. * The compile-time checks should be made available via a separate config option which can be enabled by default (or always enabled) once enough time has passed to get the issues it catches fixed. Signed-off-by: Daniel Micay <danie

  1   2   3   4   >