Date: Wed, 2 Nov 2016 23:23:10 +0200 From: Hans Liljestrand <ishkamiel@...il.com> To: Kees Cook <keescook@...omium.org> Cc: "Reshetova, Elena" <elena.reshetova@...el.com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "AKASHI, Takahiro" <takahiro.akashi@...aro.org>, "arnd@...db.de" <arnd@...db.de>, "tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "Anvin, H Peter" <h.peter.anvin@...el.com>, David Windsor <dwindsor@...il.com> Subject: Re: [RFC v3 PATCH 01/13] Add architecture independent hardened atomic base On Tue, Nov 01, 2016 at 10:19:47AM -0700, Kees Cook wrote: > (List reply got dropped?) Oh, sorry. Patching this back like this, hope that's okay. > > On Tue, Nov 1, 2016 at 8:02 AM, Hans Liljestrand <ishkamiel@...il.com> wrote: > > Thanks, should probably have thought about that! :) > > > > Still would need to do some other changes too, the macro definitions are > > currently repeated in several places, so we cannot just directly replace those > > with inline functions (e.g. we have the same ifndef->defines both in atomic and > > atomic-long, and perhaps elsewhere). Perhaps we should add a separate > > atomic_wrap header for the atomic_wrap definitions similar to local_wrap.h? > > > > Would also need to decide how HARDENED_ATOMIC implemented archs manage this. > > Currently, when not enabled, it doesn't matter whether arch _wrap functions > > exist, they just get "hidden" by the macros. Admittedly it would probably be > > better to get rid of this ambiguity too. > > If it's going to be a lot of work, perhaps skip this for now, since > maybe the other upstream folks interested in atomic won't share my > opinion. :) We can re-address it in the future, if needed. I did some quick testing with atomic_t and local_t, and got it put together relatively easy. Most of the work spent on figuring out the macro define approach applies here too. Arch specific-wise (at least as far x86 goes) this required only minor changes, mainly a bit more consistent approach to guarding _wrap definitions depending on CONFIG_HARDENED_ATOMIC. So I don't expect this would require any considerable changes for ARM either. That said, I haven't yet played around with atomic64/atomic_long_t, and probably need to take a closer look at default definitions linux/atomic.h, so I might be celebrating too soon. Best Regards, -hans liljestrand
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.