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 finer-gr
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 s
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 being
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 pr
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 bugg
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 loo
> 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.
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
> 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 i
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
> t
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 of
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
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 choos
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 jus
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.
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 servi
>> 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:
>
>
> 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 it's
09:50 +0100, Djalal 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, e
> 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 embe
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 var
Substantial added attack surface will never go away as a problem. There
aren't a finite number of vulnerabilities to be found.
> 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 tim
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 (
> 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 a
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 usually pas
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-
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: 6974f0c4555e285ab217cee58
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
> > > > w
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 s
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
> 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. !COMP
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 wante
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
> 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 deci
> [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, &optprobe_template_entry, TMPL_END_IDX);
Not a real bug, just technically undefined because
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
> >
> 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 sho
, 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: D
> 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 aga
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*.
>
> 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 paramete
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,
> > >
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
> > > > kmem_cach
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 mmap
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 o
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 architectu
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,
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 0x40UL
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 to
is takes the conservative
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
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/ in the
> 4.13/scsi-queue and for-next branches. I think that's why Kees didn't
> include it but I get he needs to add that.
s/get/guess/
Or is that repo supposed to get pulled into next?
On Fri, 2017-06-16 at 11:30 +1000, Stephen Rothwell wrote:
> Hi Kees,
>
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/bitmap.h:8:0,
> from include/linux/cpumask.h:11,
> fr
On Thu, 2017-06-15 at 16:46 -0700, Kees Cook wrote:
> On Thu, Jun 15, 2017 at 12:12 PM, Andrew Morton
> wrote:
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook
> > wrote:
> >
> > > > > Caused by commit
> > > > >
> > > > > 088a5ecf7581 ("include/linux/string.h: add the option of
> > > > > fort
> So after that the errors (x86_64 allmodconfig build) are only:
>
> In file included from include/linux/bitmap.h:8:0,
> from include/linux/cpumask.h:11,
> from arch/x86/include/asm/cpumask.h:4,
> from arch/x86/include/asm/msr.h:10,
>
On Wed, 2017-06-14 at 19:16 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:06 PM, Stephen Rothwell u> wrote:
> > Hi Kees,
> >
> > On Wed, 14 Jun 2017 18:56:30 -0700 Kees Cook
> > wrote:
> > >
> > > I sent a series for -mm (or maintainers) to merge that should
> > > catch
> > > everything.
On Wed, 2017-06-14 at 19:19 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 7:12 PM, Daniel Micay
> wrote:
> > On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
> > > Hi Daniel,
> > >
> > > On Wed, 14 Jun 2017 21:58:42 -04
On Thu, 2017-06-15 at 12:04 +1000, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Wed, 14 Jun 2017 21:58:42 -0400 Daniel Micay > wrote:
> >
> > They're false positive warnings. I think objtool has a list of
> > __noreturn functions and needs fortify_panic added
On Wed, 2017-06-14 at 18:56 -0700, Kees Cook wrote:
> On Wed, Jun 14, 2017 at 6:35 PM, Stephen Rothwell u> wrote:
> > Hi all,
> >
> > On Mon, 5 Jun 2017 17:01:17 +1000 Stephen Rothwell > g.au> wrote:
> > >
> > > After merging the akpm-current tree, today's linux-next build
> > > (x86_64
> > > a
On Wed, 2017-06-07 at 18:26 +0100, Mark Rutland wrote:
> On Wed, Jun 07, 2017 at 01:00:25PM -0400, Daniel Micay wrote:
> > > On the better bootloaders, an initramfs segment can be loaded
> > > independently (and you can have as many as required), which makes
> > > a
> On the better bootloaders, an initramfs segment can be loaded
> independently (and you can have as many as required), which makes an
> early_initramfs a more palatable vector to inject large amounts of
> entropy into the next boot than, say, modifying the kernel image
> directly at every boot/shu
> It also probably finds more architecture-specific issues and may need
> compatibility fixes for them. I could mark it as compatible with only
> arm64 and x86(_64) since they're what I've tested to build and work at
> runtime and the compile-time errors could be turned into warnings for
> now, if
On Mon, 2017-06-05 at 17:01 +1000, Stephen Rothwell wrote:
> Hi Andrew,
>
> After merging the akpm-current tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> sound/pcmcia/pdaudiocf/pdaudiocf.o: warning: objtool: .text:
> unexpected end of section
> arch/x86/ras/mce_amd_i
Rather than doing this, the base should just be split for an ELF
interpreter like PaX. It makes sense for a standalone executable to be
as low in the address space as possible. Doing that ASAP fixes issues
like this and opens up the possibility of fixing stack mapping ASLR
entropy on various archit
On 3 June 2017 at 18:54, Jeffrey Walton wrote:
> On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote:
>> ...
>> Of course this will fail on systems with no high-res timer. Are there
>> still some of those? It might be done in about 1000 times as long on a
>> system that lacks the realtime library'
On Fri, 2017-06-02 at 21:46 -0700, Kees Cook wrote:
> On Fri, Jun 2, 2017 at 8:20 AM, wrote:
> > From: Rik van Riel
> >
> > When RLIMIT_STACK is, for example, 256MB, the current code results
> > in
> > a gap between the top of the task and mmap_base of 256MB, failing to
> > take into account th
On Fri, 2017-06-02 at 21:37 -0700, Kees Cook wrote:
>
> Patches 3 and 4 need some (minor?) adjustments
It's currently a bug fix. Doing something further would be more than
fixing the bug and should probably be separate.
On Fri, 2017-06-02 at 21:22 -0700, Kees Cook wrote:
> On Fri, Jun 2, 2017 at 8:20 AM, wrote:
> > From: Rik van Riel
> >
> > When setting up mmap_base, we take care to start the mmap base
> > below the maximum extent to which the stack will grow. However,
> > we take no such precautions with PIE
On Fri, 2017-06-02 at 14:07 -0700, Andrew Morton wrote:
> On Fri, 26 May 2017 05:54:04 -0400 Daniel Micay > wrote:
>
> > This adds support for compiling with a rough equivalent to the glibc
> > _FORTIFY_SOURCE=1 feature, providing compile-time and runtime buffer
> > o
On Fri, 2017-06-02 at 17:53 +0200, Jason A. Donenfeld wrote:
> (Meanwhile...)
>
> In my own code, I'm currently playing with a workaround that looks
> like this:
>
> --- a/src/main.c
> +++ b/src/main.c
>
> +#include
> +#include
>
> +struct rng_initializer {
> + struct completion done;
>
On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote:
> On 5/30/17 4:22 PM, Daniel Micay wrote:
> > > Thanks, I didn't know that android was doing this. I still think
> > > this
> > > feature
> > > is worthwhile for people to be able to harden t
> Thanks, I didn't know that android was doing this. I still think this
> feature
> is worthwhile for people to be able to harden their systems against
> this attack
> vector without having to implement a MAC.
Since there's a capable LSM hook for ioctl already, it means it could go
in Yama with pt
> Seccomp requires the program in question to "opt-in" so to speak and set
> certain restrictions on itself. However as you state above, any TIOCSTI
> protection doesn't matter if the program correctly allocates a tty/pty pair.
> This protections seeks to protect users from programs that don't do t
is takes the conservative
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
On Thu, 2017-05-25 at 20:40 -0700, Kees Cook wrote:
> On Mon, May 22, 2017 at 4:10 PM, Daniel Micay
> wrote:
> > diff --git a/arch/x86/include/asm/string_64.h
> > b/arch/x86/include/asm/string_64.h
> > index 733bae07fb29..3c5b26e07b85 100644
> > --- a/arch/x86/inc
On Tue, 2017-05-23 at 19:12 -0700, Kees Cook wrote:
> On Tue, May 23, 2017 at 3:48 PM, Andrew Morton
> wrote:
> > On Mon, 22 May 2017 19:10:25 -0400 Daniel Micay > om> wrote:
> >
> > > This adds support for compiling with a rough equivalent to the
> >
is takes the conservative
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
obtained the canary value.
>
> Inspired by execshield ascii-armor and PaX/grsecurity.
>
> Thanks to Daniel Micay for extracting code of similar functionality
> from PaX/grsecurity and making it easy to find in his linux-hardened
> git tree on https://github.com/thestinger/linux-harden
On Wed, 2017-05-17 at 17:41 +0100, Alan Cox wrote:
> > If we're adjusting applications, they should be made to avoid
> > TIOSCTI
> > completely. This looks to me a lot like the symlink restrictions:
> > yes,
> > userspace should be fixed to the do the right thing, but why not
> > provide support to
> overflow into adjacent allocations (fixed by VMAP_STACK).
99% fixed, but it's possible to skip over the guard page without
-fstack-check enabled (plus some edge cases need to be fixed in GCC),
unless VLAs were forbidden in addition to the existing large frame size
warning.
I'm not sure about in
On Fri, 2017-05-12 at 22:06 +0100, Al Viro wrote:
> On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux
> wrote:
> > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote:
> > > I'm clearly not explaining things well enough. I shouldn't say
> > > "corruption", I should say "malic
On Wed, 2017-05-10 at 21:29 +0100, Alan Cox wrote:
>
> In addition your change to allow it to be used by root in the guest
> completely invalidates any protection you have because I can push
>
> "rm -rf /\n"
>
> as root in my namespace and exit
>
> The tty buffers are not flushed across the con
hich did not like the memcmp() of a "0 byte"
> array.
>
> Cc: Daniel Micay
> Signed-off-by: Kees Cook
> ---
> kernel/kexec_file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> in
On Mon, 2017-05-08 at 09:52 +0200, Ingo Molnar wrote:
>
> ... it's just not usable in that form for a regular maintenance flow.
>
> So what would be more useful is to add a specific Sparse check that
> only checks
> KERNEL_DS, to add it as a regular (.config driven) build option and
> make sure
Commit-ID: 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05
Gitweb: http://git.kernel.org/tip/5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05
Author: Daniel Micay
AuthorDate: Thu, 4 May 2017 09:32:09 -0400
Committer: Ingo Molnar
CommitDate: Fri, 5 May 2017 08:05:13 +0200
stackprotector: Increase the
The stack canary is an unsigned long and should be fully initialized to
random data rather than only 32 bits of random data.
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Micay
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
> grsecurity and PaX are great projects. They have a lot of good ideas,
> and they're put together quite nicely. The upstream kernel should
> *not* do things differently from they way they are in grsecurity/PaX
> just because it wants to be different. Conversely, the upstream
> kernel should not
>> Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP))
>> somewhere sensible should make those "leaks" visible fast -- and their
>> exploitation impossible, i.e. fail hard.
>
> The leaks surely exist and now we'll just add an exploitable BUG.
That didn't seem to matter for landing a
> Not too late to rename it. Scoped write? I think it makes change to
s/change/sense/
> I probably chose the wrong name for this feature (write rarely).
> That's _usually_ true, but "sensitive_write()" was getting rather
> long. The things that we need to protect with this are certainly stuff
> that doesn't get much writing, but some things are just plain
> sensitive (like page tabl
On Mon, 2017-01-16 at 15:24 +, Mark Rutland wrote:
> Hi,
>
> On Sat, Jan 14, 2017 at 11:03:14AM +0100, PaX Team wrote:
> > On 13 Jan 2017 at 14:02, Kees Cook wrote:
> >
> > > +config GCC_PLUGIN_STRUCTLEAK_VERBOSE
> > > + bool "Report initialized variables"
> > > + depends on GCC_PLUGIN_STRUCT
> This should permit Linux distributions to more comprehensively lock
> down
> their services, as it allows an isolated opt-in for hidepid= for
> specific services. Previously hidepid= could only be set system-wide,
> and then specific services had to be excluded by group membership,
> essentially
On Fri, 2016-12-16 at 11:47 -0800, Tom Herbert wrote:
>
> That's about 3x of jhash speed (7 nsecs). So that might closer
> to a more palatable replacement for jhash. Do we lose any security
> advantages with halfsiphash?
Have you tested a lower round SipHash? Probably best to stick with the
usual
> So for statics, I think `static const char *` wins due to allowing
> merging (although it doesn't matter here). For non-statics, you end up
> with extra pointer constants. Those could get removed, but Linux
> doesn't
> have -fvisibility=hidden and I'm not sure how clever linkers are.
> Maybe
> se
> Thanks for the explanation. I don't think we need to worry about
> merging these strings, but I'll keep it in mind.
>
> However, the "folklore" of the kernel was to never do:
> char *foo = "bar";
> but instead do:
> char foo[] = "bar";
> to save on the extra variable that the former
> To follow up on this, and after staring at too many outputs of the
> compiler, I think what this really should be is:
> static char const critical_overtemp_path[] =
> "/sbin/critical_overtemp";
> right?
>
> That way both the variable, and the data, end up in read-only memory
> from what I
On Thu, 2016-12-15 at 15:57 +0800, Herbert Xu wrote:
> Jason A. Donenfeld wrote:
> >
> > Siphash needs a random secret key, yes. The point is that the hash
> > function remains secure so long as the secret key is kept secret.
> > Other functions can't make the same guarantee, and so nervous
> > p
On Tue, 2016-11-01 at 07:33 +0100, Ingo Molnar wrote:
> * Pavel Machek wrote:
>
> > I'm not going to buy broken hardware just for a test.
>
> Can you suggest a method to find heavily rowhammer affected hardware?
> Only by
> testing it, or are there some chipset IDs ranges or dmidecode info
> th
On Mon, 2016-10-31 at 22:38 +0100, Florian Weimer wrote:
> * Daniel Micay:
>
> > -fstack-stack is supposed to handle a single guard by default, and
> > that's all there is for thread stacks by default.
>
> Okay, then I'll really have to look at the probing offs
On Mon, 2016-10-31 at 22:22 +0100, Jann Horn wrote:
> On Mon, Oct 31, 2016 at 10:10:41PM +0100, Florian Weimer wrote:
> > * Daniel Micay:
> >
> > > > It makes a lot of sense on x86_64 where it means the canary is
> > > > still 56 bits. Also, you
1 - 100 of 154 matches
Mail list logo
