From jussi.kivilinna at iki.fi Sat Nov 7 09:30:30 2020 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sat, 7 Nov 2020 10:30:30 +0200 Subject: [PATCH] Prevent link-time optimization from inlining __gcry_burn_stack Message-ID: <20201107083030.168239-1-jussi.kivilinna@iki.fi> * src/g10lib.h (NOINLINE_FUNC): New attribute macro. * src/misc.c (__gcry_burn_stack): Add NOINLINE_FUNC attribute. -- LTO can cause inline of __gcry_burn_stack and result tail-call to _gcry_fast_wipememory and defeat tail-call prevention in _gcry_burn_stack macro. Mark __gcry_burn_stack with 'noinline' attribute to prevent unwanted inlining of this function in LTO builds. Signed-off-by: Jussi Kivilinna --- src/g10lib.h | 6 ++++++ src/misc.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/src/g10lib.h b/src/g10lib.h index c85e6649..ffd71018 100644 --- a/src/g10lib.h +++ b/src/g10lib.h @@ -75,6 +75,12 @@ #define GCC_ATTR_UNUSED #endif +#if __GNUC__ > 3 +#define NOINLINE_FUNC __attribute__((noinline)) +#else +#define NOINLINE_FUNC +#endif + #if __GNUC__ >= 3 #define LIKELY(expr) __builtin_expect( !!(expr), 1 ) #define UNLIKELY(expr) __builtin_expect( !!(expr), 0 ) diff --git a/src/misc.c b/src/misc.c index 283e3a72..4db2d9a4 100644 --- a/src/misc.c +++ b/src/misc.c @@ -545,7 +545,7 @@ _gcry_fast_wipememory2 (void *ptr, int set, size_t len) } -void +void NOINLINE_FUNC __gcry_burn_stack (unsigned int bytes) { #ifdef HAVE_VLA -- 2.27.0 From tstellar at redhat.com Tue Nov 24 01:58:05 2020 From: tstellar at redhat.com (Tom Stellard) Date: Mon, 23 Nov 2020 16:58:05 -0800 Subject: [PATCH] Fix build of jitterentropy-base.c with clang v2 In-Reply-To: <87mu3cul6g.fsf@wheatstone.g10code.de> References: <20200727190946.14768-1-tstellar@redhat.com> <20200727200019.5761-1-tstellar@redhat.com> <87mu3cul6g.fsf@wheatstone.g10code.de> Message-ID: <2509ec56-b0e1-490f-0f01-9956c1cb6e9f@redhat.com> On 8/3/20 2:35 AM, Werner Koch wrote: > Hi! > > Thanbks for the patch. However the problem is that it is too easy to > build with optimization - there really should be an #error in case > optimization is accidently enabled (broken pragma etc.). Do you know a > macro or other mechanism in Clang so that we can check that optimization > has been disabled? > I don't know of any other way to check if optimizations are disabled. Is the goal with the check to prevent someone accidentally removing the pragma? -Tom > > Shalom-Salam, > > Werner > From smueller at chronox.de Tue Nov 24 08:25:36 2020 From: smueller at chronox.de (Stephan Mueller) Date: Tue, 24 Nov 2020 08:25:36 +0100 Subject: [PATCH] Fix build of jitterentropy-base.c with clang v2 In-Reply-To: <2509ec56-b0e1-490f-0f01-9956c1cb6e9f@redhat.com> References: <20200727190946.14768-1-tstellar@redhat.com> <20200727200019.5761-1-tstellar@redhat.com> <87mu3cul6g.fsf@wheatstone.g10code.de> <2509ec56-b0e1-490f-0f01-9956c1cb6e9f@redhat.com> Message-ID: <6bbd944a360c5361b3849fa1423d7f591bacb5ca.camel@chronox.de> Am Montag, den 23.11.2020, 16:58 -0800 schrieb Tom Stellard via Gcrypt-devel: > On 8/3/20 2:35 AM, Werner Koch wrote: > > Hi! Hi, > > > > Thanbks for the patch.? However the problem is that it is too easy to > > build with optimization - there really should be an #error in case > > optimization is accidently enabled (broken pragma etc.).? Do you know a > > macro or other mechanism in Clang so that we can check that optimization > > has been disabled? > > > > I don't know of any other way to check if optimizations are disabled. > Is the goal with the check to prevent someone accidentally removing the > pragma? Just as a side note: I am in the process of finishing up version 3.0 of the Jitter RNG code base. This now is able to run with full optimizations and has a fallback if no high-res timer is available. It is also SP800-90B compliant. Ciao Stephan > > -Tom > > > > > Shalom-Salam, > > > > ??? Werner > > > > > _______________________________________________ > Gcrypt-devel mailing list > Gcrypt-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gcrypt-devel