nettle-bugs March 2020

nettle-bugs@lists.lysator.liu.se

9 participants
35 discussions

[PATCH] Added bcrypt() support.
by Stephen R. van den Berg 18 Mar '20

18 Mar '20

--- blowfish.c | 515 ++++++++++++++++++++++++++++++++++++++++++++++++++++- blowfish.h | 5 + 2 files changed, 518 insertions(+), 2 deletions(-) diff --git a/blowfish.c b/blowfish.c index 52040f13..d0b45117 100644 --- a/blowfish.c +++ b/blowfish.c @@ -45,7 +45,12 @@ (from Nettle's blowfish.h), dropping the libgcrypt wrapper functions, fixing #include's, remove support for non-16 rounds (there are no test vectors), adding FOR_BLOCK iterations, and - running indent on the code. */ + running indent on the code. + + The lower half of this file includes code for the computation + of bcrypt hashes, which was added at a later date. + + */ #if HAVE_CONFIG_H #include "config.h" @@ -397,7 +402,7 @@ blowfish_set_key (struct blowfish_ctx *ctx, ctx->p[i] = datal; ctx->p[i + 1] = datar; } - + for (j = 0; j < 4; j++) for (i = 0; i < 256; i += 2) { @@ -428,3 +433,509 @@ blowfish128_set_key(struct blowfish_ctx *ctx, const uint8_t *key) { return blowfish_set_key (ctx, BLOWFISH128_KEY_SIZE, key); } + +/* + * The crypt_blowfish homepage is: + * + * http://www.openwall.com/crypt/ + * + * This code comes from John the Ripper password cracker, with reentrant + * and crypt(3) interfaces added, but optimizations specific to password + * cracking removed. + * + * Written by Solar Designer <solar at openwall.com> in 1998-2015. + * No copyright is claimed, and the software is hereby placed in the public + * domain. In case this attempt to disclaim copyright and place the software + * in the public domain is deemed null and void, then the software is + * Copyright (c) 1998-2015 Solar Designer and it is hereby released to the + * general public under the following terms: + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted. + * + * There's ABSOLUTELY NO WARRANTY, express or implied. + * + * It is my intent that you should be able to use this on your system, + * as part of a software package, or anywhere else to improve security, + * ensure compatibility, or for any other purpose. I would appreciate + * it if you give credit where it is due and keep your modifications in + * the public domain as well, but I don't require that in order to let + * you place this code and any modifications you make under a license + * of your choice. + * + * This implementation is fully compatible with OpenBSD's bcrypt.c for prefix + * "$2b$", originally by Niels Provos <provos at citi.umich.edu>, and it uses + * some of his ideas. The password hashing algorithm was designed by David + * Mazieres <dm at lcs.mit.edu>. For information on the level of + * compatibility for bcrypt hash prefixes other than "$2b$", please refer to + * the comments in BF_set_key() below and to the included crypt(3) man page. + * + * There's a paper on the algorithm that explains its design decisions: + * + * http://www.usenix.org/events/usenix99/provos.html + */ + +#include <string.h> + +#include <errno.h> +#ifndef __set_errno +#define __set_errno(val) errno = (val) +#endif + +typedef uint32_t BF_key[_BLOWFISH_ROUNDS + 2]; + +/* + * Magic IV for 64 Blowfish encryptions that we do at the end. + * The string is "OrpheanBeholderScryDoubt" on big-endian. + */ +static uint32_t BF_magic_w[6] = { + 0x4F727068, 0x65616E42, 0x65686F6C, + 0x64657253, 0x63727944, 0x6F756274 +}; + +static unsigned char BF_itoa64[64 + 1] = + "./ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; + +static unsigned char BF_atoi64[0x60] = { + 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 64, 0, 1, + 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 64, 64, 64, 64, 64, + 64, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, + 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 64, 64, 64, 64, 64, + 64, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, + 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 64, 64, 64, 64, 64 +}; + +#define BF_safe_atoi64(dst, src) \ +{ \ + tmp = (unsigned char)(src); \ + if ((unsigned int)(tmp -= 0x20) >= 0x60) return -1; \ + tmp = BF_atoi64[tmp]; \ + if (tmp > 63) return -1; \ + (dst) = tmp; \ +} + +static int BF_decode(uint32_t *dst, const char *src, int size) +{ + unsigned char *dptr = (unsigned char *)dst; + unsigned char *end = dptr + size; + const unsigned char *sptr = (const unsigned char *)src; + unsigned int tmp, c1, c2, c3, c4; + + do { + BF_safe_atoi64(c1, *sptr++); + BF_safe_atoi64(c2, *sptr++); + *dptr++ = (c1 << 2) | ((c2 & 0x30) >> 4); + if (dptr >= end) break; + + BF_safe_atoi64(c3, *sptr++); + *dptr++ = ((c2 & 0x0F) << 4) | ((c3 & 0x3C) >> 2); + if (dptr >= end) break; + + BF_safe_atoi64(c4, *sptr++); + *dptr++ = ((c3 & 0x03) << 6) | c4; + } while (dptr < end); + + if (end - dptr == size) + return -1; + + *dptr = 0; + + return 0; +} + +static void BF_encode(char *dst, const uint32_t *src, int size) +{ + const unsigned char *sptr = (const unsigned char *)src; + const unsigned char *end = sptr + size; + unsigned char *dptr = (unsigned char *)dst; + unsigned int c1, c2; + + do { + c1 = *sptr++; + *dptr++ = BF_itoa64[c1 >> 2]; + c1 = (c1 & 0x03) << 4; + if (sptr >= end) { + *dptr++ = BF_itoa64[c1]; + break; + } + + c2 = *sptr++; + c1 |= c2 >> 4; + *dptr++ = BF_itoa64[c1]; + c1 = (c2 & 0x0f) << 2; + if (sptr >= end) { + *dptr++ = BF_itoa64[c1]; + break; + } + + c2 = *sptr++; + c1 |= c2 >> 6; + *dptr++ = BF_itoa64[c1]; + *dptr++ = BF_itoa64[c2 & 0x3f]; + } while (sptr < end); +} + +static void BF_swap(uint32_t *x, int count) +{ + static int endianness_check = 1; + char *is_little_endian = (char *)&endianness_check; + uint32_t tmp; + + if (*is_little_endian) + do { + tmp = *x; + tmp = (tmp << 16) | (tmp >> 16); + *x++ = ((tmp & 0x00FF00FF) << 8) | ((tmp >> 8) & 0x00FF00FF); + } while (--count); +} + +static void BF_set_key(const char *key, BF_key expanded, BF_key initial, + unsigned char flags) +{ + const char *ptr = key; + unsigned int bug, i, j; + uint32_t safety, sign, diff, tmp[2]; + +/* + * There was a sign extension bug in older revisions of this function. While + * we would have liked to simply fix the bug and move on, we have to provide + * a backwards compatibility feature (essentially the bug) for some systems and + * a safety measure for some others. The latter is needed because for certain + * multiple inputs to the buggy algorithm there exist easily found inputs to + * the correct algorithm that produce the same hash. Thus, we optionally + * deviate from the correct algorithm just enough to avoid such collisions. + * While the bug itself affected the majority of passwords containing + * characters with the 8th bit set (although only a percentage of those in a + * collision-producing way), the anti-collision safety measure affects + * only a subset of passwords containing the '\xff' character (not even all of + * those passwords, just some of them). This character is not found in valid + * UTF-8 sequences and is rarely used in popular 8-bit character encodings. + * Thus, the safety measure is unlikely to cause much annoyance, and is a + * reasonable tradeoff to use when authenticating against existing hashes that + * are not reliably known to have been computed with the correct algorithm. + * + * We use an approach that tries to minimize side-channel leaks of password + * information - that is, we mostly use fixed-cost bitwise operations instead + * of branches or table lookups. (One conditional branch based on password + * length remains. It is not part of the bug aftermath, though, and is + * difficult and possibly unreasonable to avoid given the use of C strings by + * the caller, which results in similar timing leaks anyway.) + * + * For actual implementation, we set an array index in the variable "bug" + * (0 means no bug, 1 means sign extension bug emulation) and a flag in the + * variable "safety" (bit 16 is set when the safety measure is requested). + * Valid combinations of settings are: + * + * Prefix "$2a$": bug = 0, safety = 0x10000 + * Prefix "$2b$": bug = 0, safety = 0 + * Prefix "$2x$": bug = 1, safety = 0 + * Prefix "$2y$": bug = 0, safety = 0 + */ + bug = (unsigned int)flags & 1; + safety = ((uint32_t)flags & 2) << 15; + + sign = diff = 0; + + for (i = 0; i < _BLOWFISH_ROUNDS + 2; i++) { + tmp[0] = tmp[1] = 0; + for (j = 0; j < 4; j++) { + tmp[0] <<= 8; + tmp[0] |= (unsigned char)*ptr; /* correct */ + tmp[1] <<= 8; + tmp[1] |= (signed char)*ptr; /* bug */ +/* + * Sign extension in the first char has no effect - nothing to overwrite yet, + * and those extra 24 bits will be fully shifted out of the 32-bit word. For + * chars 2, 3, 4 in each four-char block, we set bit 7 of "sign" if sign + * extension in tmp[1] occurs. Once this flag is set, it remains set. + */ + if (j) + sign |= tmp[1] & 0x80; + if (!*ptr) + ptr = key; + else + ptr++; + } + diff |= tmp[0] ^ tmp[1]; /* Non-zero on any differences */ + + expanded[i] = tmp[bug]; + initial[i] = initial_ctx.p[i] ^ tmp[bug]; + } + +/* + * At this point, "diff" is zero iff the correct and buggy algorithms produced + * exactly the same result. If so and if "sign" is non-zero, which indicates + * that there was a non-benign sign extension, this means that we have a + * collision between the correctly computed hash for this password and a set of + * passwords that could be supplied to the buggy algorithm. Our safety measure + * is meant to protect from such many-buggy to one-correct collisions, by + * deviating from the correct algorithm in such cases. Let's check for this. + */ + diff |= diff >> 16; /* still zero iff exact match */ + diff &= 0xffff; /* ditto */ + diff += 0xffff; /* bit 16 set iff "diff" was non-zero (on non-match) */ + sign <<= 9; /* move the non-benign sign extension flag to bit 16 */ + sign &= ~diff & safety; /* action needed? */ + +/* + * If we have determined that we need to deviate from the correct algorithm, + * flip bit 16 in initial expanded key. (The choice of 16 is arbitrary, but + * let's stick to it now. It came out of the approach we used above, and it's + * not any worse than any other choice we could make.) + * + * It is crucial that we don't do the same to the expanded key used in the main + * Eksblowfish loop. By doing it to only one of these two, we deviate from a + * state that could be directly specified by a password to the buggy algorithm + * (and to the fully correct one as well, but that's a side-effect). + */ + initial[0] ^= sign; +} + +static const unsigned char flags_by_subtype[26] = + {2, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 4, 0}; + +static char *BF_crypt(const char *key, const char *settings, + char *output, int size, + uint32_t min) +{ + struct { + struct blowfish_ctx ctx; + BF_key expanded_key; + union { + uint32_t salt[4]; + uint32_t output[6]; + } binary; + } data; + uint32_t L, R; + uint32_t tmp1, tmp2, tmp3, tmp4; + uint32_t *ptr; + uint32_t count; + int i; + + if (size < 7 + 22 + 31 + 1) { + __set_errno(ERANGE); + return NULL; + } + + if (settings[0] != '$' || + settings[1] != '2' || + settings[2] < 'a' || settings[2] > 'z' || + !flags_by_subtype[(unsigned int)(unsigned char)settings[2] - 'a'] || + settings[3] != '$' || + settings[4] < '0' || settings[4] > '3' || + settings[5] < '0' || settings[5] > '9' || + (settings[4] == '3' && settings[5] > '1') || + settings[6] != '$') { + __set_errno(EINVAL); + return NULL; + } + + count = (uint32_t)1 << ((settings[4] - '0') * 10 + (settings[5] - '0')); + if (count < min || BF_decode(data.binary.salt, &settings[7], 16)) { + __set_errno(EINVAL); + return NULL; + } + BF_swap(data.binary.salt, 4); + + BF_set_key(key, data.expanded_key, data.ctx.p, + flags_by_subtype[(unsigned int)(unsigned char)settings[2] - 'a']); + + memcpy(data.ctx.s, initial_ctx.s, sizeof(data.ctx.s)); + + L = R = 0; + for (i = 0; i < _BLOWFISH_ROUNDS + 2; i += 2) { + L ^= data.binary.salt[i & 2]; + R ^= data.binary.salt[(i & 2) + 1]; + encrypt(&data.ctx, &L, &R); + data.ctx.p[i] = L; + data.ctx.p[i + 1] = R; + } + + ptr = data.ctx.s[0]; + do { + ptr += 4; + L ^= data.binary.salt[(_BLOWFISH_ROUNDS + 2) & 3]; + R ^= data.binary.salt[(_BLOWFISH_ROUNDS + 3) & 3]; + encrypt(&data.ctx, &L, &R); + *(ptr - 4) = L; + *(ptr - 3) = R; + + L ^= data.binary.salt[(_BLOWFISH_ROUNDS + 4) & 3]; + R ^= data.binary.salt[(_BLOWFISH_ROUNDS + 5) & 3]; + encrypt(&data.ctx, &L, &R); + *(ptr - 2) = L; + *(ptr - 1) = R; + } while (ptr < &data.ctx.s[3][0xFF]); + + do { + int done; + + for (i = 0; i < _BLOWFISH_ROUNDS + 2; i += 2) { + data.ctx.p[i] ^= data.expanded_key[i]; + data.ctx.p[i + 1] ^= data.expanded_key[i + 1]; + } + + done = 0; + do { + L = R = 0; + ptr = data.ctx.p; + do { + ptr += 2; + encrypt(&data.ctx, &L, &R); + *(ptr - 2) = L; + *(ptr - 1) = R; + } while (ptr < &data.ctx.p[_BLOWFISH_ROUNDS + 2]); + + ptr = data.ctx.s[0]; + do { + ptr += 2; + encrypt(&data.ctx, &L, &R); + *(ptr - 2) = L; + *(ptr - 1) = R; + } while (ptr < &data.ctx.s[3][0xFF]); + + if (done) + break; + done = 1; + + tmp1 = data.binary.salt[0]; + tmp2 = data.binary.salt[1]; + tmp3 = data.binary.salt[2]; + tmp4 = data.binary.salt[3]; + for (i = 0; i < _BLOWFISH_ROUNDS; i += 4) { + data.ctx.p[i] ^= tmp1; + data.ctx.p[i + 1] ^= tmp2; + data.ctx.p[i + 2] ^= tmp3; + data.ctx.p[i + 3] ^= tmp4; + } + data.ctx.p[16] ^= tmp1; + data.ctx.p[17] ^= tmp2; + } while (1); + } while (--count); + + for (i = 0; i < 6; i += 2) { + L = BF_magic_w[i]; + R = BF_magic_w[i + 1]; + + count = 64; + do { + encrypt(&data.ctx, &L, &R); + } while (--count); + + data.binary.output[i] = L; + data.binary.output[i + 1] = R; + } + + memcpy(output, settings, 7 + 22 - 1); + output[7 + 22 - 1] = BF_itoa64[(int) + BF_atoi64[(int)settings[7 + 22 - 1] - 0x20] & 0x30]; + +/* This has to be bug-compatible with the original implementation, so + * only encode 23 of the 24 bytes. :-) */ + BF_swap(data.binary.output, 6); + BF_encode(&output[7 + 22], data.binary.output, 23); + output[7 + 22 + 31] = '\0'; + + return output; +} + +static int bcrypt_output_magic(const char *settings, char *output, int size) +{ + if (size < 3) + return -1; + + output[0] = '*'; + output[1] = '0'; + output[2] = '\0'; + + if (settings[0] == '*' && settings[1] == '0') + output[1] = '1'; + + return 0; +} + +/* + * Please preserve the runtime self-test. It serves two purposes at once: + * + * 1. We really can't afford the risk of producing incompatible hashes e.g. + * when there's something like gcc bug 26587 again, whereas an application or + * library integrating this code might not also integrate our external tests or + * it might not run them after every build. Even if it does, the miscompile + * might only occur on the production build, but not on a testing build (such + * as because of different optimization settings). It is painful to recover + * from incorrectly-computed hashes - merely fixing whatever broke is not + * enough. Thus, a proactive measure like this self-test is needed. + * + * 2. We don't want to leave sensitive data from our actual password hash + * computation on the stack or in registers. Previous revisions of the code + * would do explicit cleanups, but simply running the self-test after hash + * computation is more reliable. + * + * The performance cost of this quick self-test is around 0.6% at the "$2a$08" + * setting. + */ +uint8_t *blowfish_bcrypt(const uint8_t *key, const uint8_t *settings, + uint8_t *dst, size_t length) +{ + const char *test_pw = "8b \xd0\xc1\xd2\xcf\xcc\xd8"; + const char *test_settings = "$2a$00$abcdefghijklmnopqrstuu"; + static const char * const test_hashes[2] = + {"i1D709vfamulimlGcq0qq3UvuUasvEa\0\x55", /* 'a', 'b', 'y' */ + "VUrPmXD6q/nVSSp7pNDhCR9071IfIRe\0\x55"}; /* 'x' */ + const char *test_hash = test_hashes[0]; + uint8_t *retval; + const char *p; + int save_errno, ok; + struct { + char s[7 + 22 + 1]; + char o[7 + 22 + 31 + 1 + 1 + 1]; + } buf; + +/* Hash the supplied password */ + bcrypt_output_magic(settings, dst, length); + retval = BF_crypt(key, settings, dst, length, 16); + save_errno = errno; + +/* + * Do a quick self-test. It is important that we make both calls to BF_crypt() + * from the same scope such that they likely use the same stack locations, + * which makes the second call overwrite the first call's sensitive data on the + * stack and makes it more likely that any alignment related issues would be + * detected by the self-test. + */ + memcpy(buf.s, test_settings, sizeof(buf.s)); + if (retval) { + unsigned int flags = flags_by_subtype[ + (unsigned int)(unsigned char)settings[2] - 'a']; + test_hash = test_hashes[flags & 1]; + buf.s[2] = settings[2]; + } + memset(buf.o, 0x55, sizeof(buf.o)); + buf.o[sizeof(buf.o) - 1] = 0; + p = BF_crypt(test_pw, buf.s, buf.o, sizeof(buf.o) - (1 + 1), 1); + + ok = (p == buf.o && + !memcmp(p, buf.s, 7 + 22) && + !memcmp(p + (7 + 22), test_hash, 31 + 1 + 1 + 1)); + + { + const char *k = "\xff\xa3" "34" "\xff\xff\xff\xa3" "345"; + BF_key ae, ai, ye, yi; + BF_set_key(k, ae, ai, 2); /* $2a$ */ + BF_set_key(k, ye, yi, 4); /* $2y$ */ + ai[0] ^= 0x10000; /* undo the safety (for comparison) */ + ok = ok && ai[0] == 0xdb9c59bc && ye[17] == 0x33343500 && + !memcmp(ae, ye, sizeof(ae)) && + !memcmp(ai, yi, sizeof(ai)); + } + + __set_errno(save_errno); + if (ok) + return retval; + +/* Should not happen */ + bcrypt_output_magic(settings, dst, length); + __set_errno(EINVAL); /* pretend we don't support this hash type */ + return NULL; +} diff --git a/blowfish.h b/blowfish.h index bcdc7cb6..ae7f5b12 100644 --- a/blowfish.h +++ b/blowfish.h @@ -81,6 +81,11 @@ void blowfish_decrypt(const struct blowfish_ctx *ctx, size_t length, uint8_t *dst, const uint8_t *src); +uint8_t * +blowfish_bcrypt(const uint8_t *key, + const uint8_t *settings, + uint8_t *dst, + size_t length); #ifdef __cplusplus } -- 2.20.1

1 0

Re: V3 [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by nisse＠lysator.liu.se 15 Mar '20

15 Mar '20

"H.J. Lu" <hjl.tools(a)gmail.com> writes: > You need to write a run-time test in configure.ac to check if CET is enabled > since CET requires processor, kernel and user space support. Do you think a test like this would be feasible? It needs both compile time and run time checks: 1. Check (preprocessor) if building on x86, and on an operating system with unix-style signal handling. If not, define test_main to exit with return code 77 (SKIP macro in testutils.h). 2. Use inline assembly in some way to define a trivial function with no ENDBR mark, and produce a function pointer to it. 3. If __CET__ is defined by the compiler, check for runtime support (hardware + kernel, but *not* the current mode set up based on ELF flags in the executable). If it's supported, install a signal handler for whatever for whatever signal happens on indirect jumps without ENDBR marks, and which exits the process with return code 0 (success). Call the asm function via the function pointer. If the call returns, fail the test by calling abort. 4. Otherwise, call the asm function via the function pointer, and exit with return code 77. (To exercise the inline asm, but still indicate that the feature inteded to be tested could not be tested). Then the test will fail if either we're running a CET-enabled build on a CET enabled system, but for for some reason the test executable didn't get it this protection. Or we're running on a non-CET x86 system where the inline asm is somehow broken. No additional configure checks needed (except if we want a proper test for signal/sigaction rather than depending on preprocessor predefines). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

1 0

Re: V3 [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by nisse＠lysator.liu.se 15 Mar '20

15 Mar '20

"H.J. Lu" <hjl.tools(a)gmail.com> writes: > Here is the updated patch. This V3 patch looks pretty nice to me. But I'm a bit confused by the use of ASM_X86_ENDBR. The instruction is added to entry points, via the PROLOGUE macro, but not to other branch targets, e.g., loop labels in the assembly files. Is that not needed (because branches are direct, without going via PLT indirection)? Or will the assembler insert some ENDBR instructions automatically? Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

2 2

Re: Armeb is broken
by Dmitry Baryshkov 13 Mar '20

13 Mar '20

Hello, вс, 23 февр. 2020 г. в 20:00, Michael Weiser <michael(a)weiser.dinsnail.net>: > > Hi Dmitry, > > On Sun, Feb 23, 2020 at 07:09:43PM +0300, Dmitry Baryshkov wrote: > > > I will check with fresh Yocto build later or tomorrow. > > Thanks! I have checked both armv7vet2b and armv5eb targets with qemu. Your patch fixes the issue for me. > Could Yocto be used for CI then? Do they do any kind of binary releases > for armeb? How long and voluminous is a build of an armeb system with > and without a native toolchain? No, I found no package feeds/binary releases for armeb. So to use Yocto for CI, we'd have to build an image with Yocto SDK inside. I can try implementing it. -- With best wishes Dmitry

3 8

Re: V3 [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by Simo Sorce 10 Mar '20

10 Mar '20

On Mon, 2020-03-09 at 14:59 -0700, H.J. Lu wrote: > On Mon, Mar 9, 2020 at 2:42 PM Simo Sorce <simo(a)redhat.com> wrote: > > On Mon, 2020-03-09 at 14:31 -0700, H.J. Lu wrote: > > > On Mon, Mar 9, 2020 at 2:15 PM Simo Sorce <simo(a)redhat.com> wrote: > > > > On Mon, 2020-03-09 at 12:46 -0700, H.J. Lu wrote: > > > > > On Mon, Mar 9, 2020 at 12:22 PM Simo Sorce <simo(a)redhat.com> wrote: > > > > > > On Mon, 2020-03-09 at 15:19 -0400, Simo Sorce wrote: > > > > > > > On Mon, 2020-03-09 at 11:56 -0700, H.J. Lu wrote: > > > > > > > > On Mon, Mar 9, 2020 at 11:19 AM Simo Sorce <simo(a)redhat.com> wrote: > > > > > > > > > On Mon, 2020-03-09 at 19:03 +0100, Niels Möller wrote: > > > > > > > > > > Simo Sorce <simo(a)redhat.com> writes: > > > > > > > > > > > > > > > > > > > > > The patchset i solder than I did remember, April 2019 > > > > > > > > > > > But I recall running at least one version of it on our CET emulator @ > > > > > > > > > > > Red Hat. > > > > > > > > > > > > > > > > > > > > Sorry I forgot to followup on that. It seems only the first easy cleanup > > > > > > > > > > patch, "Add missing EPILOGUEs in assembly files", was applied back then. > > > > > > > > > > > > > > > > > > > > Do you remember why you used GNU_CET_SECTION() explicitly in .asm files, > > > > > > > > > > rather than using an m4 divert? > > > > > > > > > > > > > > > > > > Not really I do not recall anymore, but I think there was a reason, as > > > > > > > > > I recall you made that comment back then and it "didn't work out" when > > > > > > > > > I tried is the memory I have of it. > > > > > > > > > Might have to do with differences in how it lays out the code when done > > > > > > > > > via m4 divert, but not 100% sure. > > > > > > > > > > > > > > > > > > > > > > > > > m4 divert requires much less changes. Here is the updated patch with > > > > > > > > ASM_X86_ENDBR, ASM_X86_MARK_CET_ALIGN and ASM_X86_MARK_CET. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Two comments on your patch. > > > > > > > > > > > > > > 1. It is an error to align based on architecture. All GNU Notes MUST be > > > > > > > aligned 8 bytes. Since 2018 GNU Libc ignores misaligned notes. > > > > > > > > > > > > Ah nevermind this point, misunderstanding with my libc expert, the 4 > > > > > > bytes alignment is ok on 32 bit code. > > > > > > > > > > > > > 2. It is better to use .pushsection .popsection pairs around the note > > > > > > > instead of .section because of the side effects of using .section > > > > > > > > > > Done. > > > > > > > > > > > > The m4 divert looks smaller impact, feel free to lift the Gnu Note > > > > > > > section in my patch #3 and place it into your patch if you want. My > > > > > > > code also made it more explicit what all the sections values actually > > > > > > > mean which will help in long term maintenance if someone else need to > > > > > > > change anything (like for example changing to enable only ShadowStack > > > > > > > vs IBT). > > > > > > > > > > > > > > > > > Since CET support requires all objects are marked for CET, CET marker on > > > > > assembly sources is controlled by compiler options, not by configure option. > > > > > Also linker can merge multiple .note.gnu.property sections in a single > > > > > input file: > > > > > > > > > > [hjl@gnu-cfl-1 tmp]$ cat p.s > > > > > .pushsection ".note.gnu.property", "a" > > > > > .p2align 3 > > > > > .long 1f - 0f > > > > > .long 4f - 1f > > > > > .long 5 > > > > > 0: > > > > > .asciz "GNU" > > > > > 1: > > > > > .p2align 3 > > > > > .long 0xc0000002 > > > > > .long 3f - 2f > > > > > 2: > > > > > .long 1 > > > > > 3: > > > > > .p2align 3 > > > > > 4: > > > > > .popsection > > > > > .pushsection ".note.gnu.property", "a" > > > > > .p2align 3 > > > > > .long 1f - 0f > > > > > .long 4f - 1f > > > > > .long 5 > > > > > 0: > > > > > .asciz "GNU" > > > > > 1: > > > > > .p2align 3 > > > > > .long 0xc0000002 > > > > > .long 3f - 2f > > > > > 2: > > > > > .long 2 > > > > > 3: > > > > > .p2align 3 > > > > > 4: > > > > > .popsection > > > > > [hjl@gnu-cfl-1 tmp]$ as -o p.o p.s -mx86-used-note=no > > > > > [hjl@gnu-cfl-1 tmp]$ readelf -n p.o > > > > > > > > > > Displaying notes found in: .note.gnu.property > > > > > Owner Data size Description > > > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > > > > > Properties: x86 feature: IBT > > > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > > > > > Properties: x86 feature: SHSTK > > > > > [hjl@gnu-cfl-1 tmp]$ ld -r p.o > > > > > [hjl@gnu-cfl-1 tmp]$ readelf -n a.out > > > > > > > > > > Displaying notes found in: .note.gnu.property > > > > > Owner Data size Description > > > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > > > > > Properties: x86 feature: IBT, SHSTK > > > > > [hjl@gnu-cfl-1 tmp]$ > > > > > > > > > > New properties can be added without changing CET marker. > > > > > > > > > > Here is the updated patch. > > > > > > > > This patch looks good to me. > > > > Unfortunately I never received the original email creating the thred, > > > > did you send other patches too ? > > > > > > This is the only patch needed to enable CET. > > > > > > > Or is the prologue stuff sufficient to pass test suite in CET emulator? > > > > > > > > > > It is sufficient to pass all tests on real CET processors with > > > > > > $ CC="gcc -Wl,-z,cet-report=error -fcf-protection" CXX="g++ > > > -Wl,-z,cet-report=error -fcf-protection" > > > /home/hjl/work/git/gitlab/nettle/configure > > > > Excellent! > > > > I wonder if we should create a negative test with an actual incorrect > > jmp instruction to verify that CET is enabled, given it is very easy to > > get the linker to disable CET if any dependency is not CET enabled. > > > > When I ran the code in the emulator I manually added a jump to a non > > endbr instruction to make sure it would fail, and it did :-) > > > > I have some CET smoke tests in violations directory at > > https://gitlab.com/cet-software/cet-smoke-test I meant as part of Nettle, so hopefully we do not regress (once CET enabled machines become available in CI systems). We can have a simple binary that links to libnettle and libhogweed and has inline assembly that jumps to a non ENDBR instruction. The test will SUCCEED if the binary crashes... The test should run only if the HW supports CET of course, I assume this is something that can be tested via /proc/cpuinfo or similar methods ? Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc

1 0

Re: V3 [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by Simo Sorce 10 Mar '20

10 Mar '20

On Mon, 2020-03-09 at 14:31 -0700, H.J. Lu wrote: > On Mon, Mar 9, 2020 at 2:15 PM Simo Sorce <simo(a)redhat.com> wrote: > > On Mon, 2020-03-09 at 12:46 -0700, H.J. Lu wrote: > > > On Mon, Mar 9, 2020 at 12:22 PM Simo Sorce <simo(a)redhat.com> wrote: > > > > On Mon, 2020-03-09 at 15:19 -0400, Simo Sorce wrote: > > > > > On Mon, 2020-03-09 at 11:56 -0700, H.J. Lu wrote: > > > > > > On Mon, Mar 9, 2020 at 11:19 AM Simo Sorce <simo(a)redhat.com> wrote: > > > > > > > On Mon, 2020-03-09 at 19:03 +0100, Niels Möller wrote: > > > > > > > > Simo Sorce <simo(a)redhat.com> writes: > > > > > > > > > > > > > > > > > The patchset i solder than I did remember, April 2019 > > > > > > > > > But I recall running at least one version of it on our CET emulator @ > > > > > > > > > Red Hat. > > > > > > > > > > > > > > > > Sorry I forgot to followup on that. It seems only the first easy cleanup > > > > > > > > patch, "Add missing EPILOGUEs in assembly files", was applied back then. > > > > > > > > > > > > > > > > Do you remember why you used GNU_CET_SECTION() explicitly in .asm files, > > > > > > > > rather than using an m4 divert? > > > > > > > > > > > > > > Not really I do not recall anymore, but I think there was a reason, as > > > > > > > I recall you made that comment back then and it "didn't work out" when > > > > > > > I tried is the memory I have of it. > > > > > > > Might have to do with differences in how it lays out the code when done > > > > > > > via m4 divert, but not 100% sure. > > > > > > > > > > > > > > > > > > > m4 divert requires much less changes. Here is the updated patch with > > > > > > ASM_X86_ENDBR, ASM_X86_MARK_CET_ALIGN and ASM_X86_MARK_CET. > > > > > > > > > > > > > > > > > > > > > > Two comments on your patch. > > > > > > > > > > 1. It is an error to align based on architecture. All GNU Notes MUST be > > > > > aligned 8 bytes. Since 2018 GNU Libc ignores misaligned notes. > > > > > > > > Ah nevermind this point, misunderstanding with my libc expert, the 4 > > > > bytes alignment is ok on 32 bit code. > > > > > > > > > 2. It is better to use .pushsection .popsection pairs around the note > > > > > instead of .section because of the side effects of using .section > > > > > > Done. > > > > > > > > The m4 divert looks smaller impact, feel free to lift the Gnu Note > > > > > section in my patch #3 and place it into your patch if you want. My > > > > > code also made it more explicit what all the sections values actually > > > > > mean which will help in long term maintenance if someone else need to > > > > > change anything (like for example changing to enable only ShadowStack > > > > > vs IBT). > > > > > > > > > > > Since CET support requires all objects are marked for CET, CET marker on > > > assembly sources is controlled by compiler options, not by configure option. > > > Also linker can merge multiple .note.gnu.property sections in a single > > > input file: > > > > > > [hjl@gnu-cfl-1 tmp]$ cat p.s > > > .pushsection ".note.gnu.property", "a" > > > .p2align 3 > > > .long 1f - 0f > > > .long 4f - 1f > > > .long 5 > > > 0: > > > .asciz "GNU" > > > 1: > > > .p2align 3 > > > .long 0xc0000002 > > > .long 3f - 2f > > > 2: > > > .long 1 > > > 3: > > > .p2align 3 > > > 4: > > > .popsection > > > .pushsection ".note.gnu.property", "a" > > > .p2align 3 > > > .long 1f - 0f > > > .long 4f - 1f > > > .long 5 > > > 0: > > > .asciz "GNU" > > > 1: > > > .p2align 3 > > > .long 0xc0000002 > > > .long 3f - 2f > > > 2: > > > .long 2 > > > 3: > > > .p2align 3 > > > 4: > > > .popsection > > > [hjl@gnu-cfl-1 tmp]$ as -o p.o p.s -mx86-used-note=no > > > [hjl@gnu-cfl-1 tmp]$ readelf -n p.o > > > > > > Displaying notes found in: .note.gnu.property > > > Owner Data size Description > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > > > Properties: x86 feature: IBT > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > > > Properties: x86 feature: SHSTK > > > [hjl@gnu-cfl-1 tmp]$ ld -r p.o > > > [hjl@gnu-cfl-1 tmp]$ readelf -n a.out > > > > > > Displaying notes found in: .note.gnu.property > > > Owner Data size Description > > > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > > > Properties: x86 feature: IBT, SHSTK > > > [hjl@gnu-cfl-1 tmp]$ > > > > > > New properties can be added without changing CET marker. > > > > > > Here is the updated patch. > > > > This patch looks good to me. > > Unfortunately I never received the original email creating the thred, > > did you send other patches too ? > > This is the only patch needed to enable CET. > > > Or is the prologue stuff sufficient to pass test suite in CET emulator? > > > > It is sufficient to pass all tests on real CET processors with > > $ CC="gcc -Wl,-z,cet-report=error -fcf-protection" CXX="g++ > -Wl,-z,cet-report=error -fcf-protection" > /home/hjl/work/git/gitlab/nettle/configure Excellent! I wonder if we should create a negative test with an actual incorrect jmp instruction to verify that CET is enabled, given it is very easy to get the linker to disable CET if any dependency is not CET enabled. When I ran the code in the emulator I manually added a jump to a non endbr instruction to make sure it would fail, and it did :-) -- Simo Sorce RHEL Crypto Team Red Hat, Inc

1 0

Re: V3 [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by Simo Sorce 10 Mar '20

10 Mar '20

On Mon, 2020-03-09 at 12:46 -0700, H.J. Lu wrote: > On Mon, Mar 9, 2020 at 12:22 PM Simo Sorce <simo(a)redhat.com> wrote: > > On Mon, 2020-03-09 at 15:19 -0400, Simo Sorce wrote: > > > On Mon, 2020-03-09 at 11:56 -0700, H.J. Lu wrote: > > > > On Mon, Mar 9, 2020 at 11:19 AM Simo Sorce <simo(a)redhat.com> wrote: > > > > > On Mon, 2020-03-09 at 19:03 +0100, Niels Möller wrote: > > > > > > Simo Sorce <simo(a)redhat.com> writes: > > > > > > > > > > > > > The patchset i solder than I did remember, April 2019 > > > > > > > But I recall running at least one version of it on our CET emulator @ > > > > > > > Red Hat. > > > > > > > > > > > > Sorry I forgot to followup on that. It seems only the first easy cleanup > > > > > > patch, "Add missing EPILOGUEs in assembly files", was applied back then. > > > > > > > > > > > > Do you remember why you used GNU_CET_SECTION() explicitly in .asm files, > > > > > > rather than using an m4 divert? > > > > > > > > > > Not really I do not recall anymore, but I think there was a reason, as > > > > > I recall you made that comment back then and it "didn't work out" when > > > > > I tried is the memory I have of it. > > > > > Might have to do with differences in how it lays out the code when done > > > > > via m4 divert, but not 100% sure. > > > > > > > > > > > > > m4 divert requires much less changes. Here is the updated patch with > > > > ASM_X86_ENDBR, ASM_X86_MARK_CET_ALIGN and ASM_X86_MARK_CET. > > > > > > > > > > > > > > Two comments on your patch. > > > > > > 1. It is an error to align based on architecture. All GNU Notes MUST be > > > aligned 8 bytes. Since 2018 GNU Libc ignores misaligned notes. > > > > Ah nevermind this point, misunderstanding with my libc expert, the 4 > > bytes alignment is ok on 32 bit code. > > > > > 2. It is better to use .pushsection .popsection pairs around the note > > > instead of .section because of the side effects of using .section > > Done. > > > > The m4 divert looks smaller impact, feel free to lift the Gnu Note > > > section in my patch #3 and place it into your patch if you want. My > > > code also made it more explicit what all the sections values actually > > > mean which will help in long term maintenance if someone else need to > > > change anything (like for example changing to enable only ShadowStack > > > vs IBT). > > > > > Since CET support requires all objects are marked for CET, CET marker on > assembly sources is controlled by compiler options, not by configure option. > Also linker can merge multiple .note.gnu.property sections in a single > input file: > > [hjl@gnu-cfl-1 tmp]$ cat p.s > .pushsection ".note.gnu.property", "a" > .p2align 3 > .long 1f - 0f > .long 4f - 1f > .long 5 > 0: > .asciz "GNU" > 1: > .p2align 3 > .long 0xc0000002 > .long 3f - 2f > 2: > .long 1 > 3: > .p2align 3 > 4: > .popsection > .pushsection ".note.gnu.property", "a" > .p2align 3 > .long 1f - 0f > .long 4f - 1f > .long 5 > 0: > .asciz "GNU" > 1: > .p2align 3 > .long 0xc0000002 > .long 3f - 2f > 2: > .long 2 > 3: > .p2align 3 > 4: > .popsection > [hjl@gnu-cfl-1 tmp]$ as -o p.o p.s -mx86-used-note=no > [hjl@gnu-cfl-1 tmp]$ readelf -n p.o > > Displaying notes found in: .note.gnu.property > Owner Data size Description > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > Properties: x86 feature: IBT > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > Properties: x86 feature: SHSTK > [hjl@gnu-cfl-1 tmp]$ ld -r p.o > [hjl@gnu-cfl-1 tmp]$ readelf -n a.out > > Displaying notes found in: .note.gnu.property > Owner Data size Description > GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 > Properties: x86 feature: IBT, SHSTK > [hjl@gnu-cfl-1 tmp]$ > > New properties can be added without changing CET marker. > > Here is the updated patch. This patch looks good to me. Unfortunately I never received the original email creating the thred, did you send other patches too ? Or is the prologue stuff sufficient to pass test suite in CET emulator? -- Simo Sorce RHEL Crypto Team Red Hat, Inc

1 0

Re: [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by Simo Sorce 10 Mar '20

10 Mar '20

On Mon, 2020-03-09 at 11:56 -0700, H.J. Lu wrote: > On Mon, Mar 9, 2020 at 11:19 AM Simo Sorce <simo(a)redhat.com> wrote: > > On Mon, 2020-03-09 at 19:03 +0100, Niels Möller wrote: > > > Simo Sorce <simo(a)redhat.com> writes: > > > > > > > The patchset i solder than I did remember, April 2019 > > > > But I recall running at least one version of it on our CET emulator @ > > > > Red Hat. > > > > > > Sorry I forgot to followup on that. It seems only the first easy cleanup > > > patch, "Add missing EPILOGUEs in assembly files", was applied back then. > > > > > > Do you remember why you used GNU_CET_SECTION() explicitly in .asm files, > > > rather than using an m4 divert? > > > > Not really I do not recall anymore, but I think there was a reason, as > > I recall you made that comment back then and it "didn't work out" when > > I tried is the memory I have of it. > > Might have to do with differences in how it lays out the code when done > > via m4 divert, but not 100% sure. > > > > m4 divert requires much less changes. Here is the updated patch with > ASM_X86_ENDBR, ASM_X86_MARK_CET_ALIGN and ASM_X86_MARK_CET. > > Two comments on your patch. 1. It is an error to align based on architecture. All GNU Notes MUST be aligned 8 bytes. Since 2018 GNU Libc ignores misaligned notes. 2. It is better to use .pushsection .popsection pairs around the note instead of .section because of the side effects of using .section The m4 divert looks smaller impact, feel free to lift the Gnu Note section in my patch #3 and place it into your patch if you want. My code also made it more explicit what all the sections values actually mean which will help in long term maintenance if someone else need to change anything (like for example changing to enable only ShadowStack vs IBT). Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc

1 1

[PATCH v2 1/3] chacha: add function to set initial block counter
by Daiki Ueno 10 Mar '20

10 Mar '20

From: Daiki Ueno <dueno(a)redhat.com> The ChaCha20 based header protection algorithm in QUIC requires a way to set the initial value of counter: https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-chacha20-based… This will add a new function chacha_set_counter, which takes an 8-octet initial value of the block counter. Signed-off-by: Daiki Ueno <dueno(a)redhat.com> --- chacha-set-nonce.c | 7 +++++++ chacha.h | 5 +++++ nettle.texinfo | 12 ++++++++++++ testsuite/chacha-test.c | 37 +++++++++++++++++++++++++++++++++++-- 4 files changed, 59 insertions(+), 2 deletions(-) diff --git a/chacha-set-nonce.c b/chacha-set-nonce.c index 607f176b..2c34e498 100644 --- a/chacha-set-nonce.c +++ b/chacha-set-nonce.c @@ -68,3 +68,10 @@ chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t *nonce) ctx->state[14] = LE_READ_UINT32(nonce + 4); ctx->state[15] = LE_READ_UINT32(nonce + 8); } + +void +chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter) +{ + ctx->state[12] = LE_READ_UINT32(counter + 0); + ctx->state[13] = LE_READ_UINT32(counter + 4); +} diff --git a/chacha.h b/chacha.h index 429a55b6..440fe968 100644 --- a/chacha.h +++ b/chacha.h @@ -46,6 +46,7 @@ extern "C" { #define chacha_set_key nettle_chacha_set_key #define chacha_set_nonce nettle_chacha_set_nonce #define chacha_set_nonce96 nettle_chacha_set_nonce96 +#define chacha_set_counter nettle_chacha_set_counter #define chacha_crypt nettle_chacha_crypt /* Currently, only 256-bit keys are supported. */ @@ -53,6 +54,7 @@ extern "C" { #define CHACHA_BLOCK_SIZE 64 #define CHACHA_NONCE_SIZE 8 #define CHACHA_NONCE96_SIZE 12 +#define CHACHA_COUNTER_SIZE 8 #define _CHACHA_STATE_LENGTH 16 @@ -81,6 +83,9 @@ chacha_set_nonce(struct chacha_ctx *ctx, const uint8_t *nonce); void chacha_set_nonce96(struct chacha_ctx *ctx, const uint8_t *nonce); +void +chacha_set_counter(struct chacha_ctx *ctx, const uint8_t *counter); + void chacha_crypt(struct chacha_ctx *ctx, size_t length, uint8_t *dst, const uint8_t *src); diff --git a/nettle.texinfo b/nettle.texinfo index 19eb6d34..0b339f51 100644 --- a/nettle.texinfo +++ b/nettle.texinfo @@ -1669,6 +1669,10 @@ ChaCha block size, 64. Size of the nonce, 8. @end defvr +@defvr Constant CHACHA_COUNTER_SIZE +Size of the counter, 8. +@end defvr + @deftypefun void chacha_set_key (struct chacha_ctx *@var{ctx}, const uint8_t *@var{key}) Initialize the cipher. The same function is used for both encryption and decryption. Before using the cipher, @@ -1681,6 +1685,14 @@ octets. This function also initializes the block counter, setting it to zero. @end deftypefun +@deftypefun void chacha_set_counter (struct chacha_ctx *@var{ctx}, const uint8_t *@var{counter}) +Sets the block counter. It is always of size @code{CHACHA_COUNTER_SIZE}, +8 octets. This is rarely needed since @code{chacha_set_nonce} +initializes the block counter to zero. When it is still necessary, this +function must be called after @code{chacha_set_nonce}. + +@end deftypefun + @deftypefun void chacha_crypt (struct chacha_ctx *@var{ctx}, size_t @var{length}, uint8_t *@var{dst}, const uint8_t *@var{src}) Encrypts or decrypts the data of a message, using ChaCha. When a message is encrypted using a sequence of calls to @code{chacha_crypt}, diff --git a/testsuite/chacha-test.c b/testsuite/chacha-test.c index d6489e9c..6875d4bb 100644 --- a/testsuite/chacha-test.c +++ b/testsuite/chacha-test.c @@ -38,8 +38,9 @@ #include "chacha-internal.h" static void -test_chacha(const struct tstring *key, const struct tstring *nonce, - const struct tstring *expected, unsigned rounds) +_test_chacha(const struct tstring *key, const struct tstring *nonce, + const struct tstring *expected, unsigned rounds, + const struct tstring *counter) { struct chacha_ctx ctx; @@ -69,6 +70,9 @@ test_chacha(const struct tstring *key, const struct tstring *nonce, else die ("Bad nonce size %u.\n", (unsigned) nonce->length); + if (counter) + chacha_set_counter(&ctx, counter->data); + chacha_crypt (&ctx, length, data, data); ASSERT (data[-1] == 17); @@ -98,6 +102,8 @@ test_chacha(const struct tstring *key, const struct tstring *nonce, ASSERT (nonce->length == CHACHA_NONCE_SIZE); chacha_set_nonce(&ctx, nonce->data); + if (counter) + chacha_set_counter(&ctx, counter->data); _chacha_core (out, ctx.state, rounds); if (!MEMEQ(CHACHA_BLOCK_SIZE, out, expected->data)) @@ -117,6 +123,21 @@ test_chacha(const struct tstring *key, const struct tstring *nonce, } } +static void +test_chacha(const struct tstring *key, const struct tstring *nonce, + const struct tstring *expected, unsigned rounds) +{ + _test_chacha(key, nonce, expected, rounds, NULL); +} + +static void +test_chacha_with_counter(const struct tstring *key, const struct tstring *nonce, + const struct tstring *expected, unsigned rounds, + const struct tstring *counter) +{ + _test_chacha(key, nonce, expected, rounds, counter); +} + void test_main(void) { @@ -644,4 +665,16 @@ test_main(void) "d2826446079faa09 14c2d705d98b02a2" "b5129cd1de164eb9 cbd083e8a2503c4e"), 20); + + /* This is identical to the 96-bit nonce test, but it manually sets + the counter value */ + test_chacha_with_counter(SHEX("0001020304050607 08090a0b0c0d0e0f" + "1011121314151617 18191a1b1c1d1e1f"), + SHEX("0000004a00000000"), + SHEX("10f1e7e4d13b5915 500fdd1fa32071c4" + "c7d1f4c733c06803 0422aa9ac3d46c4e" + "d2826446079faa09 14c2d705d98b02a2" + "b5129cd1de164eb9 cbd083e8a2503c4e"), + 20, + SHEX("0100000000000009")); } -- 2.24.1

2 3

Re: [PATCH] x86: Add X86_ENDBR and CET marker to config.m4.in
by Simo Sorce 09 Mar '20

09 Mar '20

On Mon, 2020-03-09 at 08:33 -0700, H.J. Lu wrote: > On Mon, Mar 9, 2020 at 5:36 AM Simo Sorce <simo(a)redhat.com> wrote: > > On Sat, 2020-03-07 at 17:49 +0100, Niels Möller wrote: > > > "H.J. Lu" <hjl.tools(a)gmail.com> writes: > > > > > > > Intel Control-flow Enforcement Technology (CET): > > > > > > > > https://software.intel.com/en-us/articles/intel-sdm > > > > > > > > contains shadow stack (SHSTK) and indirect branch tracking (IBT). When > > > > CET is enabled, ELF object files must be marked with .note.gnu.property > > > > section. Also when IBT is enabled, all indirect branch targets must > > > > start with ENDBR instruction. > > > > > > > > This patch adds X86_ENDBR and the CET marker to config.m4.in when CET > > > > is enabled. It updates PROLOGUE with X86_ENDBR. > > > > > > I'd like to have a look at what gcc produces. How is it enabled with > > > gcc? In the docs, I find > > > > > > -mshstk > > > > > > The -mshstk option enables shadow stack built-in functions from x86 > > > Control-flow Enforcement Technology (CET). > > > > > > but when I try compiling a trivial function, > > > > > > $ cat foo-cet.c > > > int foo(void) {return 0;} > > > $ gcc -save-temps -c -mshstk foo-cet.c > > > > > > I get no endbr instruction and no note in the foo-cet.s. I'm using > > > gcc-8.3. I do get an > > > > > > .section .note.GNU-stack,"",@progbits > > > > > > corresponding to Nettle's ASM_MARK_NOEXEC_STACK > > > > > > > --- a/config.m4.in > > > > +++ b/config.m4.in > > > > @@ -8,6 +8,10 @@ define(<ALIGN_LOG>, <@ASM_ALIGN_LOG@>)dnl > > > > define(<W64_ABI>, <@W64_ABI@>)dnl > > > > define(<RODATA>, <@ASM_RODATA@>)dnl > > > > define(<WORDS_BIGENDIAN>, <@ASM_WORDS_BIGENDIAN@>)dnl > > > > +define(<X86_ENDBR>,<@X86_ENDBR@>)dnl > > > > +divert(1) > > > > +@X86_GNU_PROPERTY@ > > > > +divert > > > > divert(1) > > > > @ASM_MARK_NOEXEC_STACK@ > > > > divert > > > > > > You can put the two properties in the same m4 divert. Also, please > > > rename the autoconf substitutions with ASM_ prefix, and something more > > > descriptive than X64_GNU_PROPERTY. E.g., ASM_X86_ENDBR and > > > ASM_X86_MARK_CET. > > > > > > > diff --git a/configure.ac b/configure.ac > > > > index ba3ab7c6..e9ed630c 100644 > > > > --- a/configure.ac > > > > +++ b/configure.ac > > > > @@ -803,6 +803,82 @@ EOF > > > > ASM_ALIGN_LOG="$nettle_cv_asm_align_log" > > > > fi > > > > > > > > +dnl Define > > > > +dnl 1. X86_ENDBR for endbr32/endbr64. > > > > +dnl 2. X86_GNU_PROPERTY to add a .note.gnu.property section to mark > > > > +dnl Intel CET support if needed. > > > > +dnl .section ".note.gnu.property", "a" > > > > +dnl .p2align POINTER-ALIGN > > > > +dnl .long 1f - 0f > > > > +dnl .long 4f - 1f > > > > +dnl .long 5 > > > > +dnl 0: > > > > +dnl .asciz "GNU" > > > > +dnl 1: > > > > +dnl .p2align POINTER-ALIGN > > > > +dnl .long 0xc0000002 > > > > +dnl .long 3f - 2f > > > > +dnl 2: > > > > +dnl .long 3 > > > > +dnl 3: > > > > +dnl .p2align POINTER-ALIGN > > > > +dnl 4: > > > > > > No need to repeat the definition in full in this comment. And as I think > > > I've said before, I'm a bit surprised that it needs to be this verbose. > > > > > > > +AC_CACHE_CHECK([if Intel CET is enabled], > > > > + [nettle_cv_asm_x86_intel_cet], > > > > + [AC_TRY_COMPILE([ > > > > +#ifndef __CET__ > > > > +#error Intel CET is not enabled > > > > +#endif > > > > + ], [], > > > > + [nettle_cv_asm_x86_intel_cet=yes], > > > > + [nettle_cv_asm_x86_intel_cet=no])]) > > > > +if test "$nettle_cv_asm_x86_intel_cet" = yes; then > > > > + case $ABI in > > > > + 32|standard) > > > > + X86_ENDBR=endbr32 > > > > + p2align=2 > > > > + ;; > > > > + 64) > > > > + X86_ENDBR=endbr64 > > > > + p2align=3 > > > > + ;; > > > > + x32) > > > > + X86_ENDBR=endbr64 > > > > + p2align=2 > > > > + ;; > > > > + esac > > > > + AC_CACHE_CHECK([if .note.gnu.property section is needed], > > > > + [nettle_cv_asm_x86_gnu_property], > > > > + [AC_TRY_COMPILE([ > > > > +#if !defined __ELF__ || !defined __CET__ > > > > +#error GNU property is not needed > > > > +#endif > > > > + ], [], > > > > + [nettle_cv_asm_x86_gnu_property=yes], > > > > + [nettle_cv_asm_x86_gnu_property=no])]) > > > > +else > > > > + nettle_cv_asm_x86_gnu_property=no > > > > +fi > > > > +if test "$nettle_cv_asm_x86_gnu_property" = yes; then > > > > + X86_GNU_PROPERTY=" > > > > + .section \".note.gnu.property\", \"a\" > > > > + .p2align $p2align > > > > + .long 1f - 0f > > > > + .long 4f - 1f > > > > + .long 5 > > > > +0: > > > > + .asciz \"GNU\" > > > > +1: > > > > + .p2align $p2align > > > > + .long 0xc0000002 > > > > + .long 3f - 2f > > > > +2: > > > > + .long 3 > > > > +3: > > > > + .p2align $p2align > > > > +4:" > > > > +fi > > > > > > Maybe a bit easier to read if you use single quotes for > > > X86_GNU_PROPERTY='...', don't escape the inner double quotes. That > > > leaves the expansion of $p2align, maybe it's better to define a separate > > > substituted variable for pointer alignment? (If there's no easier way to > > > enforce pointer-alignment). > > > > Niels, > > I sent patches longa few months ago on the list to enable CET, they > > already went through review, any reason why we are looking at a > > different set and restarting review from scratch now? > > > > (sorry for not catching earlier, we seem to be having some delivery > > issues and sometimes mailing list post are not reaching me, please keep > > me in direct CC for now, hopefully that will help :-/ ) > > > > Hi Simo, > > master branch doesn't contain any CET support. Can you share your patch > with me? I will give it a try on CET processor. > > Thanks. The patchset i solder than I did remember, April 2019 But I recall running at least one version of it on our CET emulator @ Red Hat. HTH, Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

nettle-bugs March 2020