[PATCH 0/2] target/arm: Implement an IMPDEF pauth algorithm

Richard Henderson posted 2 patches 3 years, 8 months ago
Test docker-quick@centos7 failed
Test docker-mingw@fedora failed
Test checkpatch failed
Test FreeBSD failed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20200812065339.2030527-1-richard.henderson@linaro.org
Maintainers: Peter Maydell <peter.maydell@linaro.org>
There is a newer version of this series
target/arm/cpu64.c        | 64 +++++++++++++++++++++++++++++++++
target/arm/pauth_helper.c | 75 ++++++++++++++++++++++++++++++++++++---
2 files changed, 134 insertions(+), 5 deletions(-)
[PATCH 0/2] target/arm: Implement an IMPDEF pauth algorithm
Posted by Richard Henderson 3 years, 8 months ago
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