From: Jan Beulich <jbeulich@suse.com>
To: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>,
Krystian Hebel <krystian.hebel@3mdeb.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Anthony PERARD" <anthony.perard@vates.tech>,
"Michal Orzel" <michal.orzel@amd.com>,
"Julien Grall" <julien@xen.org>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
trenchboot-devel@googlegroups.com,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH 09/21] lib/sha1.c: add file
Date: Tue, 22 Apr 2025 17:36:22 +0200 [thread overview]
Message-ID: <a0dcf27e-a066-4e5f-97b2-e5f178e1b941@suse.com> (raw)
In-Reply-To: <8dec423182ed60e2233ed87d98066fed6dc20caf.1745172094.git.sergii.dmytruk@3mdeb.com>
On 22.04.2025 17:06, Sergii Dmytruk wrote:
> From: Krystian Hebel <krystian.hebel@3mdeb.com>
>
> The code comes from [1] and is licensed under GPL-2.0 license.
> It's a combination of:
> - include/crypto/sha1.h
> - include/crypto/sha1_base.h
> - lib/crypto/sha1.c
> - crypto/sha1_generic.c
>
> Changes:
> - includes
> - formatting
> - renames and splicing of some trivial functions that are called once
> - dropping of `int` return values (only zero was ever returned)
> - getting rid of references to `struct shash_desc`
Since you did move the code to (largely) Xen style, a few further requests
in that direction:
> --- /dev/null
> +++ b/xen/include/xen/sha1.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __XEN_SHA1_H
> +#define __XEN_SHA1_H
> +
> +#include <xen/inttypes.h>
> +
> +#define SHA1_DIGEST_SIZE 20
> +
> +void sha1_hash(const u8 *data, unsigned int len, u8 *out);
uint8_t please in both instances here, and more generally {,u}int<N>_t
in place of {s,u}<N>.
> --- a/xen/lib/Makefile
> +++ b/xen/lib/Makefile
> @@ -38,6 +38,7 @@ lib-y += strtoll.o
> lib-y += strtoul.o
> lib-y += strtoull.o
> lib-$(CONFIG_X86) += x86-generic-hweightl.o
> +lib-$(CONFIG_X86) += sha1.o
Please obey to alphabetic sorting.
> --- /dev/null
> +++ b/xen/lib/sha1.c
> @@ -0,0 +1,240 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * SHA1 routine optimized to do word accesses rather than byte accesses,
> + * and to avoid unnecessary copies into the context array.
> + *
> + * This was based on the git SHA1 implementation.
> + */
> +
> +#include <xen/bitops.h>
> +#include <xen/types.h>
> +#include <xen/sha1.h>
> +#include <xen/unaligned.h>
> +
> +/*
> + * If you have 32 registers or more, the compiler can (and should)
> + * try to change the array[] accesses into registers. However, on
> + * machines with less than ~25 registers, that won't really work,
> + * and at least gcc will make an unholy mess of it.
> + *
> + * So to avoid that mess which just slows things down, we force
> + * the stores to memory to actually happen (we might be better off
> + * with a 'W(t)=(val);asm("":"+m" (W(t))' there instead, as
> + * suggested by Artur Skawina - that will also make gcc unable to
> + * try to do the silly "optimize away loads" part because it won't
> + * see what the value will be).
> + *
> + * Ben Herrenschmidt reports that on PPC, the C version comes close
> + * to the optimized asm with this (ie on PPC you don't want that
> + * 'volatile', since there are lots of registers).
> + *
> + * On ARM we get the best code generation by forcing a full memory barrier
> + * between each SHA_ROUND, otherwise gcc happily get wild with spilling and
> + * the stack frame size simply explode and performance goes down the drain.
> + */
> +
> +#ifdef CONFIG_X86
> + #define setW(x, val) (*(volatile uint32_t *)&W(x) = (val))
The # of pre-processor directives generally wants to be in the first column.
> +#elif defined(CONFIG_ARM)
> + #define setW(x, val) do { W(x) = (val); __asm__("":::"memory"); } while ( 0 )
__asm__ ( "" ::: "memory" );
as far as style goes. But then I see no need to open-code barrier().
> +#else
> + #define setW(x, val) (W(x) = (val))
> +#endif
> +
> +/* This "rolls" over the 512-bit array */
> +#define W(x) (array[(x) & 15])
> +
> +/*
> + * Where do we get the source from? The first 16 iterations get it from
> + * the input data, the next mix it from the 512-bit array.
> + */
> +#define SHA_SRC(t) get_unaligned_be32((uint32_t *)data + t)
> +#define SHA_MIX(t) rol32(W(t + 13) ^ W(t + 8) ^ W(t + 2) ^ W(t), 1)
I fear Misra isn't going to like the lack of parenthesization of macro
arguments used in expressions. This looks to be an issue with most
macros here.
> +#define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
> + uint32_t TEMP = input(t); setW(t, TEMP); \
> + E += TEMP + rol32(A, 5) + (fn) + (constant); \
> + B = ror32(B, 2); \
> + TEMP = E; E = D; D = C; C = B; B = A; A = TEMP; \
> + } while ( 0 )
> +
> +#define T_0_15(t, A, B, C, D, E) \
> + SHA_ROUND(t, SHA_SRC, (((C ^ D) & B) ^ D), 0x5a827999, A, B, C, D, E)
> +#define T_16_19(t, A, B, C, D, E) \
> + SHA_ROUND(t, SHA_MIX, (((C ^ D) & B) ^ D), 0x5a827999, A, B, C, D, E)
> +#define T_20_39(t, A, B, C, D, E) \
> + SHA_ROUND(t, SHA_MIX, (B ^ C ^ D), 0x6ed9eba1, A, B, C, D, E)
> +#define T_40_59(t, A, B, C, D, E) \
> + SHA_ROUND(t, SHA_MIX, ((B & C) + (D & (B ^ C))), 0x8f1bbcdc, A, B, C, \
> + D, E)
> +#define T_60_79(t, A, B, C, D, E) \
> + SHA_ROUND(t, SHA_MIX, (B ^ C ^ D), 0xca62c1d6, A, B, C, D, E)
> +
> +#define SHA1_BLOCK_SIZE 64
> +#define SHA1_WORKSPACE_WORDS 16
> +
> +struct sha1_state {
> + uint32_t state[SHA1_DIGEST_SIZE / 4];
> + uint64_t count;
> + uint8_t buffer[SHA1_BLOCK_SIZE];
> +};
> +
> +typedef void sha1_block_fn(struct sha1_state *sst, const uint8_t *src, int blocks);
Please respect line length restrictions. The use of plain int here also looks
questionable, as just from the name that parameter looks like it can't have a
negative argument passed for it. This will want adjusting elsewhere as well.
> +/**
> + * sha1_transform - single block SHA1 transform (deprecated)
> + *
> + * @digest: 160 bit digest to update
> + * @data: 512 bits of data to hash
> + * @array: 16 words of workspace (see note)
> + *
> + * This function executes SHA-1's internal compression function. It updates the
> + * 160-bit internal state (@digest) with a single 512-bit data block (@data).
> + *
> + * Don't use this function. SHA-1 is no longer considered secure. And even if
> + * you do have to use SHA-1, this isn't the correct way to hash something with
> + * SHA-1 as this doesn't handle padding and finalization.
> + *
> + * Note: If the hash is security sensitive, the caller should be sure
> + * to clear the workspace. This is left to the caller to avoid
> + * unnecessary clears between chained hashing operations.
> + */
> +void sha1_transform(uint32_t *digest, const uint8_t *data, uint32_t *array)
You add no declaration of this function in the header. Should it be static?
This would also help with the "Don't use ..." part of the comment.
Jan
next prev parent reply other threads:[~2025-04-22 15:36 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 15:06 [PATCH 00/21] x86: Trenchboot Secure Launch DRTM (Xen) Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 01/21] x86/include/asm/intel_txt.h: constants and accessors for TXT registers and heap Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 02/21] include/xen/slr_table.h: Secure Launch Resource Table definitions Sergii Dmytruk
2025-04-22 20:23 ` Andrew Cooper
2025-04-23 14:40 ` Sergii Dmytruk
2025-04-22 20:46 ` ross.philipson
2025-04-23 14:47 ` Sergii Dmytruk
2025-04-23 17:33 ` ross.philipson
2025-04-22 15:06 ` [PATCH 03/21] x86/boot: add MLE header and new entry point Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 04/21] x86/boot/slaunch_early: implement early initialization Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 05/21] x86/boot/slaunch_early: early TXT checks and boot data retrieval Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 06/21] xen/arch/x86: reserve TXT memory Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 07/21] x86/mtrr: expose functions for pausing caching Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 08/21] x86/intel_txt.c: restore boot MTRRs Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 09/21] lib/sha1.c: add file Sergii Dmytruk
2025-04-22 15:36 ` Jan Beulich [this message]
2025-04-22 22:15 ` Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 10/21] lib/sha256.c: " Sergii Dmytruk
2025-04-22 15:37 ` Andrew Cooper
2025-04-22 22:20 ` Sergii Dmytruk
2025-04-22 15:39 ` Jan Beulich
2025-04-22 15:06 ` [PATCH 11/21] x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2) Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 12/21] x86/tpm.c: support extending PCRs of TPM2.0 Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 13/21] x86/hvm: Check for VMX in SMX when slaunch active Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 14/21] x86/tpm.c: implement event log for TPM2.0 Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 15/21] x86/boot: choose AP stack based on APIC ID Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 16/21] x86/smpboot.c: TXT AP bringup Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 17/21] arch/x86: process DRTM policy Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 18/21] x86/boot: find MBI and SLRT on AMD Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 19/21] arch/x86: support slaunch with AMD SKINIT Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 20/21] x86/slaunch: support EFI boot Sergii Dmytruk
2025-04-22 15:06 ` [PATCH 21/21] x86/cpu: report SMX, TXT and SKINIT capabilities Sergii Dmytruk
2025-04-22 15:23 ` [PATCH 00/21] x86: Trenchboot Secure Launch DRTM (Xen) Jan Beulich
2025-04-22 18:33 ` Sergii Dmytruk
2025-04-22 17:14 ` Andrew Cooper
2025-04-22 19:01 ` Nicola Vetrini
2025-04-23 13:38 ` Andrew Cooper
2025-04-23 18:45 ` Sergii Dmytruk
2025-04-23 20:11 ` Nicola Vetrini
2025-04-23 21:53 ` Sergii Dmytruk
2025-04-24 10:54 ` Nicola Vetrini
2025-04-24 18:14 ` Sergii Dmytruk
2025-04-23 22:43 ` Andrew Cooper
2025-04-24 18:47 ` Sergii Dmytruk
2025-04-24 18:51 ` Andrew Cooper
2025-04-25 13:33 ` Sergii Dmytruk
2025-04-23 18:59 ` Daniel P. Smith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a0dcf27e-a066-4e5f-97b2-e5f178e1b941@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=anthony.perard@vates.tech \
--cc=julien@xen.org \
--cc=krystian.hebel@3mdeb.com \
--cc=michal.orzel@amd.com \
--cc=roger.pau@citrix.com \
--cc=sergii.dmytruk@3mdeb.com \
--cc=sstabellini@kernel.org \
--cc=trenchboot-devel@googlegroups.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.