From: Richard Henderson <richard.henderson@linaro.org>
To: qemu-devel@nongnu.org
Cc: mark.rutland@arm.com, peter.maydell@linaro.org, alex.bennee@linaro.org
Subject: [PATCH 0/2] target/arm: Implement an IMPDEF pauth algorithm
Date: Tue, 11 Aug 2020 23:53:37 -0700 [thread overview]
Message-ID: <20200812065339.2030527-1-richard.henderson@linaro.org> (raw)
With recent linux kernels, which are built with pauth
enabled, boot times have been significantly impacted.
It turns out the architected pac algorithm is expensive
to implement without hardware accel.
I tried replacing this with AES128, which most hosts
have in hardware. I did manage to make this perform
fairly well, but it *really* depends on the quality of
the crypto library shipped by the OS:
(0) For reference, pauth_computepac_architected consumes
about 80% of the total runtime for a debug-enabled
kernel build. That's a 400% slowdown.
(1) libgcrypt performed well, with 15% of the total runtime,
or about 18% slowdown.
(2a) libnettle, as shipped by ubuntu 18, does not have
the x86_64 aes instruction set enabled, and so is not
using the available hw accel. That took about 40% of
the total runtime or 170% slowdown.
(2b) Rebuilding libnettle locally, with --enable-fat, and
using LD_LIBRARY_PATH to replace the system version,
worked fairly well, with about 20% of the total runtime
or 25% slowdown.
(2c) libnettle doesn't have support for armv8, ppc or s390.
Those hosts should *really* be using libgcrypt.
But, silly me, I had used --target-list=aarch64-softmmu for
this testing, in order to speed up the builds. When I went
back to building aarch64-linux-user, I was reminded that we
don't link linux-user binaries against the crypto libraries.
And those crypto libraries are usually only distributed as
shared libraries, which would cause problems for --static.
I very briefly looked into doing my own aes implementation,
with host cpu detection. But aside from the ugliness of that,
it begs the question of what to do if there's no host accel.
I settled on a fast non-cryptographic hash with about 10% overhead.
I added a -cpu max,pauth={off,impdef,arch} property to choose
between the different algorithms. The default remains arch,
since that's what 5.0 and 5.1 shipped. We can discuss whether
it makes sense to change the default for "max".
r~
Richard Henderson (2):
target/arm: Add cpu property to control pauth
target/arm: Implement an IMPDEF pauth algorithm
target/arm/cpu64.c | 64 +++++++++++++++++++++++++++++++++
target/arm/pauth_helper.c | 75 ++++++++++++++++++++++++++++++++++++---
2 files changed, 134 insertions(+), 5 deletions(-)
--
2.25.1
next reply other threads:[~2020-08-12 6:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-12 6:53 Richard Henderson [this message]
2020-08-12 6:53 ` [PATCH 1/2] target/arm: Add cpu property to control pauth Richard Henderson
2020-08-12 11:00 ` Andrew Jones
2020-08-12 15:10 ` Richard Henderson
2020-08-12 16:31 ` Andrew Jones
2020-08-13 6:03 ` Andrew Jones
2020-08-13 9:05 ` Mark Rutland
2020-08-13 9:49 ` Andrew Jones
2020-08-13 11:10 ` Mark Rutland
2020-08-12 6:53 ` [PATCH 2/2] target/arm: Implement an IMPDEF pauth algorithm Richard Henderson
2020-08-12 9:49 ` Alex Bennée
2020-08-12 15:13 ` Richard Henderson
2020-08-12 17:13 ` Alex Bennée
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=20200812065339.2030527-1-richard.henderson@linaro.org \
--to=richard.henderson@linaro.org \
--cc=alex.bennee@linaro.org \
--cc=mark.rutland@arm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.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 NNTP newsgroup(s).