From: Jarkko Sakkinen <jarkko@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: keyrings@vger.kernel.org
Subject: Re: [PATCH keyutils] test: Hide endianness
Date: Wed, 30 Apr 2025 19:04:47 +0300 [thread overview]
Message-ID: <aBJKH22UePEBneAg@kernel.org> (raw)
In-Reply-To: <2813085.1745332819@warthog.procyon.org.uk>
On Tue, Apr 22, 2025 at 03:40:19PM +0100, David Howells wrote:
> Hi Jarkko,
>
> Having tried a bunch of ways to determine the cpu endianness so that I can
> generate model content to compare against the raw contents of a keying, I
> think it might be better to sidestep the problem and rely on 'od' to byteswap
> the raw contents and then compare. What do you think?
It's a heck a lot less convoluted at least.
>
> David
> ---
> test: Hide endianness
>
> Hide the endianness of the raw binary contents of a keyring by passing it
> through /usr/bin/od which will automatically byteswap it in 4-byte chunks
> rather than trying to detect the endianness by examining what may be a
> binary file to obtain a string the format of which changes over time.
>
> Signed-off-by: David Howells <dhowells@redhat.com>
> ---
> tests/keyctl/reading/valid/runtest.sh | 9 ++-------
> tests/toolbox.inc.sh | 36 +++++++++++++++++++++++-------------
> 2 files changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/tests/keyctl/reading/valid/runtest.sh b/tests/keyctl/reading/valid/runtest.sh
> index 2fb88b9..2527f13 100644
> --- a/tests/keyctl/reading/valid/runtest.sh
> +++ b/tests/keyctl/reading/valid/runtest.sh
> @@ -40,13 +40,8 @@ expect_payload payload "67697a7a 617264"
>
> # read the contents of the keyring as hex and match it to the key ID
> marker "READ KEYRING"
> -read_key $keyringid
> -tmp=`printf %08x $keyid`
> -if [ "$endian" = "LE" ]
> -then
> - tmp=`echo $tmp | sed 's/\(..\)\(..\)\(..\)\(..\)/\4\3\2\1/'`
> -fi
> -expect_payload payload $tmp
> +pipe_key_int32 $keyringid
> +expect_payload payload $keyid
>
> # remove read permission from the key and try reading it again
> # - we should still have read permission because it's searchable in our
> diff --git a/tests/toolbox.inc.sh b/tests/toolbox.inc.sh
> index 609a6c7..6f4fb18 100644
> --- a/tests/toolbox.inc.sh
> +++ b/tests/toolbox.inc.sh
> @@ -12,19 +12,6 @@
>
> echo === $OUTPUTFILE ===
>
> -endian=`file -L /proc/$$/exe`
> -if expr "$endian" : '.* MSB \+\(pie executable\|executable\|shared object\).*' >&/dev/null
> -then
> - endian=BE
> -elif expr "$endian" : '.* LSB \+\(pie executable\|executable\|shared object\).*' >&/dev/null
> -then
> - endian=LE
> -else
> - echo -e "+++ \e[31;1mCan't Determine Endianness\e[0m"
> - echo "+++ Can't Determine Endianness" >>$OUTPUTFILE
> - exit 2
> -fi
> -
> maxtypelen=31
> maxtype=`for ((i=0; i<$((maxtypelen)); i++)); do echo -n a; done`
>
> @@ -1055,6 +1042,29 @@ function pipe_key ()
> fi
> }
>
> +###############################################################################
> +#
> +# pipe a key's raw payload to od to stdout, displaying it as a sequence of
> +# 32-bit numbers, appropriately byteswapped.
> +#
> +###############################################################################
> +function pipe_key_int32 ()
> +{
> + my_exitval=0
> + if [ "x$1" = "x--fail" ]
> + then
> + my_exitval=1
> + shift
> + fi
> +
> + echo keyctl pipe $1 \| od -t u4 -A none >>$OUTPUTFILE
> + echo `keyctl pipe $1 | od -t u4 -A none` >>$OUTPUTFILE 2>&1
> + if [ $? != $my_exitval ]
> + then
> + failed
> + fi
> +}
> +
> ###############################################################################
> #
> # pipe a key's raw payload through md5sum
>
Yeah, I mean it's also a change from text processing tool to a binary
tool (from complex to simple), so IMHO this quite obvious:
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
BR, Jarkko
prev parent reply other threads:[~2025-04-30 16:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 14:40 [PATCH keyutils] test: Hide endianness David Howells
2025-04-30 16:04 ` Jarkko Sakkinen [this message]
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=aBJKH22UePEBneAg@kernel.org \
--to=jarkko@kernel.org \
--cc=dhowells@redhat.com \
--cc=keyrings@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).