Dear Maintainer,

I found a timing side-channel while reading through the source of crypto/aes.c
I initially reported a security issue to upstream, they told me that since it's
only used by TCG and TCG is not considered secure, they don't consider it a
security issue. I then reported the security issue to debian, I was told to
create an upstream bug and a matching debian bug.

https://gitlab.com/qemu-project/qemu/-/issues/2946

much of the code in crypto/aes.c accesses memory arrays where the array index
is based on the secret data being encrypted/decrypted. because of cpu caches
and other things that can delay memory accesses based on their address, this
is a timing side-channel, potentially allowing leaking secrets over a network
based on timing how long cryptography operations take.

compare to openssl which uses an algorithm where its execution time doesn't
depend on the data being processed:
https://github.com/openssl/openssl/commit/0051746e03c65f5970d8ca424579d50f58a877e0

I reported it as a security issue since i think it's a real security issue that
should be fixed, since quite a lot of people use QEMU TCG and
expect it to not have broken cryptography. (also cuz I'm hoping to
get a bug bounty from Google later.)

Control: severity -1 wishlist
Control: tag -1 + upstream confirmed
...

I don't see the reason for this bug report either.  TCG is not used for
for any security-sensitive processing.  If you need to run a real guest,
you should use kvm instead (and run your guest on a native processor),
and there, hardware implementation of AES is used.

Yes, in TCG mode, we've a timing "issue", and it'd be nice if it had no
security implications, but it's definitely of a very low priority.

Thanks,

/mjt