From mboxrd@z Thu Jan 1 00:00:00 1970 Reply-To: kernel-hardening@lists.openwall.com Message-ID: <1476260730.19479.3.camel@cvidal.org> From: Colin Vidal Date: Wed, 12 Oct 2016 10:25:30 +0200 In-Reply-To: References: <1476016472.2329.38.camel@cvidal.org> <1476040182.2329.72.camel@cvidal.org> <20161009193731.GD14666@pc.thejh.net> <2236FBA76BA1254E88B949DDB74E612B41BDCAF6@IRSMSX102.ger.corp.intel.com> <1476115319.2329.108.camel@cvidal.org> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [kernel-hardening] self introduction To: kernel-hardening@lists.openwall.com, AKASHI Takahiro , Kees Cook Cc: "Reshetova, Elena" List-ID: > > 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