>> Specification says that AVX instruction will generate #UD exception if >> XCR0 is not set up appropriately. > > Which is indeed what happens, and that's the bug in OpenSSL we were > trying to fix. OpenSSL assumed (against the spec) that XSAVE=0 implies > AVX=0, and didn't check whether AVX needed to be masked; that was wrong.
What I tried to say is that I'd argue that assumption is *not* against specification. Specification doesn't explicitly permit XSAVE=0 AVX=1 combination, but it does imply that there may be no *real* CPU with this combination of flags. Indeed, specification ties AVX and XCR0 together and per specification there is no XCR0 without XSAVE. And if there may be no real CPU, why would virtual be permitted? >> But you can't deny the *possibility* that there is 32-bit OS that is >> aware of XSAVE and explicitly zeros XCR0[2:1]. > > It can explicitly zero XCR0[1] and still use FXSAVE/FXRSTOR. That's why > I say clear_xmm is not necessary: XCR0[1] does not imply that SSE is > useless. But that's an imaginary scenario, so I'm fine with the code > you've patched as is. It's as imaginary as your virtual CPU, so we call it even :-) :-) :-) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
