nettle-bugs

nettle-bugs@lists.lysator.liu.se

2219 discussions

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

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

09 Mar '20

"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). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677. Internet email is subject to wholesale government surveillance.

3 3

[PATCH] cmac-des3: add meta declaration to Nettle library
by dbaryshkov＠gmail.com 09 Mar '20

09 Mar '20

From: Dmitry Baryshkov <dbaryshkov(a)gmail.com> Move cmac-des3 meta information from testsuite/cmac-test.c to main Nettle library. Signed-off-by: Dmitry Baryshkov <dbaryshkov(a)gmail.com> --- Makefile.in | 2 +- cmac-des3-meta.c | 52 +++++++++++++++++++++++++++++++++++++++ nettle-meta-macs.c | 1 + nettle-meta.h | 1 + testsuite/cmac-test.c | 12 --------- testsuite/meta-mac-test.c | 1 + 6 files changed, 56 insertions(+), 13 deletions(-) create mode 100644 cmac-des3-meta.c diff --git a/Makefile.in b/Makefile.in index d4fcb81302a2..ddc304285321 100644 --- a/Makefile.in +++ b/Makefile.in @@ -103,7 +103,7 @@ nettle_SOURCES = aes-decrypt-internal.c aes-decrypt.c \ gcm-camellia128.c gcm-camellia128-meta.c \ gcm-camellia256.c gcm-camellia256-meta.c \ cmac.c cmac64.c cmac-aes128.c cmac-aes256.c cmac-des3.c \ - cmac-aes128-meta.c cmac-aes256-meta.c \ + cmac-aes128-meta.c cmac-aes256-meta.c cmac-des3-meta.c \ gost28147.c gosthash94.c gosthash94-meta.c \ hmac.c hmac-gosthash94.c hmac-md5.c hmac-ripemd160.c \ hmac-sha1.c hmac-sha224.c hmac-sha256.c hmac-sha384.c \ diff --git a/cmac-des3-meta.c b/cmac-des3-meta.c new file mode 100644 index 000000000000..7fdee8e680cf --- /dev/null +++ b/cmac-des3-meta.c @@ -0,0 +1,52 @@ +/* cmac-des3-meta.c + + Copyright (C) 2020 Dmitry Baryshkov + + This file is part of GNU Nettle. + + GNU Nettle is free software: you can redistribute it and/or + modify it under the terms of either: + + * the GNU Lesser General Public License as published by the Free + Software Foundation; either version 3 of the License, or (at your + option) any later version. + + or + + * the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your + option) any later version. + + or both in parallel, as here. + + GNU Nettle is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + General Public License for more details. + + You should have received copies of the GNU General Public License and + the GNU Lesser General Public License along with this program. If + not, see http://www.gnu.org/licenses/. +*/ + +#if HAVE_CONFIG_H +# include "config.h" +#endif + +#include <assert.h> + +#include "nettle-meta.h" + +#include "cmac.h" + +const struct nettle_mac nettle_cmac_des3 = +{ + "cmac_des3", + sizeof(struct cmac_des3_ctx), + CMAC64_DIGEST_SIZE, + DES3_KEY_SIZE, + + (nettle_set_key_func*) cmac_des3_set_key, + (nettle_hash_update_func*) cmac_des3_update, + (nettle_hash_digest_func*) cmac_des3_digest +}; diff --git a/nettle-meta-macs.c b/nettle-meta-macs.c index cb9ede851573..a658ee39e230 100644 --- a/nettle-meta-macs.c +++ b/nettle-meta-macs.c @@ -40,6 +40,7 @@ const struct nettle_mac * const _nettle_macs[] = { &nettle_cmac_aes128, &nettle_cmac_aes256, + &nettle_cmac_des3, &nettle_hmac_md5, &nettle_hmac_ripemd160, &nettle_hmac_sha1, diff --git a/nettle-meta.h b/nettle-meta.h index 5d86615f94cc..7a6af363426b 100644 --- a/nettle-meta.h +++ b/nettle-meta.h @@ -276,6 +276,7 @@ nettle_get_macs (void); extern const struct nettle_mac nettle_cmac_aes128; extern const struct nettle_mac nettle_cmac_aes256; +extern const struct nettle_mac nettle_cmac_des3; /* HMAC variants with key size = digest size */ extern const struct nettle_mac nettle_hmac_md5; diff --git a/testsuite/cmac-test.c b/testsuite/cmac-test.c index 1a2cd0e591cf..a71baa086d01 100644 --- a/testsuite/cmac-test.c +++ b/testsuite/cmac-test.c @@ -2,18 +2,6 @@ #include "nettle-internal.h" #include "cmac.h" -const struct nettle_mac nettle_cmac_des3 = -{ - "CMAC-3DES", - sizeof(struct cmac_des3_ctx), - CMAC64_DIGEST_SIZE, - DES3_KEY_SIZE, - - (nettle_set_key_func*) cmac_des3_set_key, - (nettle_hash_update_func*) cmac_des3_update, - (nettle_hash_digest_func*) cmac_des3_digest -}; - #define test_cmac_aes128(key, msg, ref) \ test_mac(&nettle_cmac_aes128, key, msg, ref) diff --git a/testsuite/meta-mac-test.c b/testsuite/meta-mac-test.c index 32b6f20f07cd..55339441c99f 100644 --- a/testsuite/meta-mac-test.c +++ b/testsuite/meta-mac-test.c @@ -4,6 +4,7 @@ const char* macs[] = { "cmac_aes128", "cmac_aes256", + "cmac_des3", "hmac_md5", "hmac_ripemd160", "hmac_sha1", -- 2.24.1

2 1

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

07 Mar '20

2 3

[PATCH] chacha: add function to set the initial value of counter
by Daiki Ueno 04 Mar '20

04 Mar '20

2 2

Jump to page:

2026

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