Re: [kernel-hardening] self introduction

[Colin Vidal <colin@cvidal.org>]

> > So, I will try to start to port PAX_REFCOUNT arm-specific features
> > to hardened_atomic_on_next, and keep you in touch. Is there a
> > deadline?  (4.10 / 5.0 merge window?)
>
> You may want to compare notes with Takahiro (CCed) who may have
> started to look at arm64 (and maybe arm too).

Thanks, I would be grateful!

> As for a deadline, as Elena says, we have no specific target. ("As
> soon as possible.") The only thing around timing that I like to see
> is persistent progress: if a patch series goes up for review,
> getting people to take a look at it, ask questions, make comments,
> and then hopefully within a week or so, the next version comes
> up. Momentum is easier to maintain than to build. ;)

OK, good! I will have more time to work on it this WE, still I began to
familiarize myself with atomic_t internals (and PaX patch).

I noticed the build is broken for non-x86 architecture (at least
arm/arm64), since basically each arch needs to provide atomic_*_wrap()
functions. Is there plans to have (probably dummies) functions in case
the architecture does not implements this functionality? I noticed the
list of define atomic_*_wrap at the end of atomic-long.h, but it does
not seems to works (they are defined after the call sites in the
expansion of previous macros).

Apart from that, in case of over-/underflow, hardened_atomic_overflow()
is called to hang the system if CONFIG_HARDENED_ATOMIC is set. I don't
get why the test in arch/x86/include/kernel/traps.c

	if (trapnr == X86_TRAP_OF)
        	hardened_atomic_overflow(regs);

is not guarded by CONFIG_HARDENED_ATOMIC: the trap cannot occurs if
CONFIG_HARDENED_ATOMIC is unset (since "int" instructions in
arch/x86/include/asm/atomic.h are guarded by it), and it would avoid
the other implementation of hardened_atomic_overflow in
include/asm-generic/bug.h.

> > [1] https://pax.grsecurity.net/pax-linux-3.6-201210022100.patch
>
> This is a quite old version of PaX. (Note the date.) If you want to
> examine PaX separately from Grsecurity (noting differences can be
> enlightening), check here:
>
> https://www.grsecurity.net/~paxguy1/?C=M;O=D

Thanks!

Colin