linux-kernel - Re: [PATCH] selftests/sgx: Fix an enclave built with extended instructions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMusb+Q4O4A9Ay7Sdz5LEe0g1fw_w6j2xgC9HOBYhhOk8i0XWQ@mail.gmail.com>
Date: Wed, 9 Apr 2025 19:17:07 +0200
From: Vladis Dronov <vdronov@...hat.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: linux-sgx@...r.kernel.org, Jarkko Sakkinen <jarkko@...nel.org>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/sgx: Fix an enclave built with extended instructions

On Wed, Apr 9, 2025 at 7:07 PM Dave Hansen <dave.hansen@...el.com> wrote:
>
> On 4/9/25 09:55, Vladis Dronov wrote:
> ...
> > Fix this by adding "-mno-avx" to ENCL_CFLAGS in Makefile. Add some comments
> > about this to code locations where enclave's xfrm field is set.
> >
> > Suggested-by: Dave Hansen <dave.hansen@...ux.intel.com>
> > Signed-off-by: Vladis Dronov <vdronov@...hat.com>
>
> First of all, this looks fine to me:
>
> Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
>
> The code comments are fine. I'm much less picky about selftests.
>
> I'm also open to other solutions here. We could, for instance, set
> xfrm=7 to allow AVX2 instructions (which are generated by
> "--with-arch_64=x86-64-v3") or use some compiler flags other than
> "-mno-avx".
>
> But "-mno-avx" does seem good to me.
>

Thank you for the ACK, Dave.

I've tested an enclave with xfrm=7 and it errors out at the AVX512
instruction (namely, vmovdqa64) in the same way. So if there is a
compiler built with "--with-arch_64=x86-64-v4" in some future, we
would get into the exact same situation.

So I believe a solution when we disable extended instruction sets
in an enclave as one covering all future cases.