New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Nope, still returns
OPENSSL_ia32cap=0x80202001478bfffd:0x0000000000000000:0x0000000000000000:0x0000000000000000:0x0000000000000000Okay that means it's working fine, you just have an old CPU so only LV0 is set. Notice how now it's
0x80202001478bfffdbut before it was0x82202001478bfffd. That means, after that reboot, it's successfully enabled AES-NI.Restart the shell or
source /etc/environmentto get the modified value back and tryopenssl speed -evp aes-256-ctragain and you should see substantial improvements compared to before the reboot.It was more or less the same, cannot really say there is a substantial improvement but if it worked. I wonder if upgrading the kernel will help (I am on 6.12 currently) and doing setcpuid=153.
I think in your case openssl is not seeing the
OPENSSL_ia32capenvironment variable at all.It'll let you know whenever it's overriding the cpuid flags, a snippet from my own tests:
(See the
env:0x82382203478bfffdat the end.)Also in my Gcore VM it's significantly faster:
No, it is. It showed a different output after he unset the variable.
The output with the variable intact:
The output after he unset it (note the 0x822... became 0x802...):
So it definitely sees it, but if nothing is actually happening performance-wise, there must be another reason.
Ya something is not working on my VM.
Ahhh, me weeb-brain misread that.
Can you try
OPENSSL_ia32cap=0x82382203478bfffd openssl speed -elapsed -evp aes-256-ctrLooks like my value works for you?
68163.34kvs3239646.55kAh, seems like it did the trick, even though I still get zeros everywhere in the output of
openssl info -cpusettingsThat's normal for your CPU, given that you got that even after you did that
unsetcommand.I thought it was weird at first, but apparently the CPU is just old.
Yep, welcome to Armenia but well...it is what it is, hopefully it will give my tor relay a boost.
If you don't have much RAM, another thing that'll give it a nice boost is this:
That'll reduce RAM usage by ~70%, which can improve performance significantly on low-memory systems. It replaces the default Glibc memory allocator, ptmalloc3, with one called jemalloc2 which is much better at resisting memory fragmentation.
Simply incorrect not sure where you people are educated.
Yes ChaCha20 has seen wide mass adoption especially in VPN space, but AES and other original forms of encryption have had plenty of there own developments are are still heavy more implemented overall.
AES-GCM, AES-GCM-SIV are actively modern competitors that still take use of hardware acceleration.
Let’s not forget AES-XTS for other applications outside of general web traffic, data encryption king.
1Gb, fix applied, many thanks.
Also if anyone else is gooning in AES-GCM like me, enabling PCLMULQDQ alongside AES-NI will speed up AES-GCM even further.
Just had to use
's/(0x[0-9a-f]{16})/sprintf("0x%016x", hex($1) | (1 << 57) | (1 << 33))/e'as the perl argument.Are there even any CPUs wit VT that do not have AES? Atom maybe?
This is for when the host CPU does support AES-NI but the flag is not set on the VM's CPU.
For instance Gcore's basic VMs don't have AES-NI flag set but the host CPU does in fact support it.
I didn't even think about whether or not the QEMU virtual CPU would use PCLMULQDQ, I just assumed it would. Wow, if it's not enabled in there then that's even worse, and
(1 << 57) | (1 << 33)is definitely a good idea!That's wild. Thanks for posting this.
What is the motivation for a host to not pass through aes support? I would think it would actually reduce CPU usage overall. And if you do have someone who pounds the CPU because you have AES passed through, they'd be easy to spot and discipline.
Nice. Thanks @forest !
If you try to do a live migration when the whole CPU is passed through, things can break if you migrate to different hardware that lacks a feature that is currently being used, so hosts will often set the advertised CPU model to be the lowest common denominator in their fleet (e.g. Broadwell if that's what their oldest node is running). Then they might be missing out on a bit of performance by not advertising some existing and very modern optimizations, but not too much.
Unfortunately some hosts are lazy or not very experienced and will just use the default qemu64 "CPU model" which is intended to be compatible with anything that is possibly running today, all the way down to a system running the original SLS Linux. It doesn't even advertise SSE4 which is from 20 years ago!
Each CPU model is basically just an alias for a collection of supported flags, so
-cpu IvyBridgeis the equivalent of setting-cpu base,+foo,+bar,+baz,...where foo, bar, and baz represent the list of features that a genuine Intel Xeon E3-12xx v2 supports. So if it's actually running on a Xeon E5-2695 v4, you could live migrate it to a real Xeon E3-12xx v2.QEMU CPU models and recognized flags (click to expand)
So what do you recommend for the providers to provide other than stock Qemu? Should the hosts try to set the flags for each hardware that they own or are there any better alternatives in general which could help a provider and how well does firecracker compare to Qemu.
and What are (if any) some things that you recommend providers to do?
Also I must say that it was a good writeup and I enjoyed reading your post :-D
Unless the provider is going to be doing live migrations, they should just do
-cpu host(aka enabling passthrough, which would be the same as manually setting the flags for that specific hardware to everything it supports). Otherwise they should just set the type to the oldest in their fleet. If they decommission their oldest node and now their "new" oldest is a different model, they can just change the configuration on all the nodes to expose that model instead.For example, my MetroVPS shows as "Intel Core Processor (Broadwell, IBRS)" which means they set
-cpu Broadwell-v3, even though it's probably running something newer under the hood. But that means they can live migrate to anything that old or newer, generally. So even though I'm not getting 100% of the features of the real CPU (assuming the node's real CPU isn't actually a Broadwell), I'm still getting all the really important ones like AES-NI, AVX2, RDRAND, SMAP, etc.Since most low-end hosts aren't going to need to do live migration like some superscalar, they should just set host CPU passthrough. The majority of my VPSes do that, with the exceptions of MetroVPS and Trabia (
-cpu Broadwell-v3) and NoAckHosting (-cpu qemu64,+aes, which is the base QEMU model but with an override to additionally pass AES-NI).Make sense, though some googling reveals that AES-NI was available in CPUs from 2010 onwards. Then again, >16-year-old CPUs would not surprise me for some hosts...
And any host with a >16 year old CPU is probably not going to be doing live migration anyway.
Come to think of it, I could write a program that automatically checks for the presence of every feature and determines exactly what flags the underlying host hardware really supports. Just some inline asm to attempt to issue a representative instruction for each feature and catch the SIGILL when it's unsupported.
For example, if it issues AESENC and it doesn't cause an illegal instruction trap (which raises SIGILL), then it means the underlying hardware supports AES-NI. If not, it means it doesn't. Same with most other CPU features.
If I turn this into a real project, I could even have a library preloaded in
/etc/ld.so.preloadthat uses a constructor to runarch_prctl(ARCH_SET_CPUID, 0)so that the instruction traps, and install a SIGSEGV handler that emulates the result so the CPUID that applications see matches (as far as performance extensions are concerned) what the host actually provides. Combined with settingsetcpuidon newer kernels, it could give the guest full performance back.Look forward to it!
Unfortunately, it seems that
ARCH_SET_CPUIDonly works on Intel processors. But pretty much all important uses of AES-NI (and PCLMULQDQ and a few other common important features like AVX2) can be changed by usingOPENSSL_ia32cap,setcpuid, andGLIBC_TUNABLES=glibc.cpu.hwcaps(the latter of which is necessary for optimized string functions in glibc). But it should still help with a majority of applications. Maybe a minority might usegetauxval(AT_HWCAP / AT_HWCAP2).So I'll write a program to automate that instead, which should still solve 90% of use-cases.
It'll be necessary to wait for kernel 6.15 to get AVX2 optimizations though, because those require kernel support (for XSAVE) which requires
setcpuid. But AES-NI and PCLMULQDQ will work in userspace even on older kernels.Annoyingly, No Ack Hosting (https://noackhosting.se) has just told me they cannot do host passthrough or accept any flag passthrough besides AES-NI, so for everything but unauthenticated AES, I'm stuck with pre-2005 features. Apparently, the last time they "tried to add special flags" they lost the whole node and had to spend 8 hours bringing it back.
Well, at least I have been able to forcibly re-enable PCLMULQDQ, but I'm still stuck without important security features, including some which allow cross-VM snooping and even breaking encryption due to low-entropy at boot (a problem that was solved in 2012). So yeah... If they didn't allow exits, I'd be cancelling right now.
They say it's a limit of the Hostbill control software, but they really have no reason not to just enable full CPU passthrough (which Hostbill can do). I can re-enable all the performance features I need myself since they aren't disabled, just not advertised, but some of the security-relevant features actually do require hypervisor cooperation, sadly. I won't be an MJJ and argue with him in tickets about whether or not host CPU passthrough "exposes the host to the guests" or try to convince him that, yes, virtio-rng is something that is used for VPSes, so I'll have to leave it be. It is what it is.