[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1476260730.19479.3.camel@cvidal.org>
Date: Wed, 12 Oct 2016 10:25:30 +0200
From: Colin Vidal <colin@...dal.org>
To: kernel-hardening@...ts.openwall.com, AKASHI Takahiro
<takahiro.akashi@...aro.org>, Kees Cook <keescook@...omium.org>
Cc: "Reshetova, Elena" <elena.reshetova@...el.com>, AKASHI Takahiro
<takahiro.akashi@...aro.org>
Subject: Re: self introduction
> > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
