From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9C71C4332F for ; Wed, 2 Nov 2022 16:29:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231786AbiKBQ3A (ORCPT ); Wed, 2 Nov 2022 12:29:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47552 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231320AbiKBQ2i (ORCPT ); Wed, 2 Nov 2022 12:28:38 -0400 Received: from mail.zytor.com (unknown [IPv6:2607:7c80:54:3::138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99DFD13F; Wed, 2 Nov 2022 09:24:16 -0700 (PDT) Received: from [127.0.0.1] ([73.223.250.219]) (authenticated bits=0) by mail.zytor.com (8.17.1/8.17.1) with ESMTPSA id 2A2GN1Vs193304 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 2 Nov 2022 09:23:02 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 2A2GN1Vs193304 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2022100601; t=1667406185; bh=2qhL9paa9Bl7NcpRAYoQBHnYYys+tFYJuc63a/wNIYo=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=KhcjIUs4JOQM6QdM8BkvkEYHy5B5naetJ5p05f4nXNwi7dHQsUlNXGHq9sSP+kGLB w2D9rEwDL+UAMJpOa3ENcn+m28FA3FjKPH3C5UlwNkOjoPbY5xpuk0mRfLsaQaa6v2 CKW6UyQTl9lHGXaPWnv92pbKoRDNFr3vTo6ykHLkJtHG4pE8vCblV0HBXu0GQx2Ozk sq1IZBPhFyr1NWLC+iQBEsiYH7oaPuFNwk9Gwyz4HoJtPoA7JleF+w8f9p8zSa46+i VkstF+w7FahRyvNMT7YpOiWemAqf7ReKeNBGDhVbspPLUdPzlvFF6ymSsPK0bZI1y2 aKlLPae2S9gnQ== Date: Wed, 02 Nov 2022 09:23:00 -0700 From: "H. Peter Anvin" To: "Elliott, Robert (Servers)" , Paolo Bonzini , Borislav Petkov , Maxim Levitsky CC: "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Herbert Xu , Jiri Olsa , Mark Rutland , "linux-perf-users@vger.kernel.org" , "open list:CRYPTO API" Subject: =?US-ASCII?Q?RE=3A_=5BPATCH_v2_1/5=5D_perf/x86/intel/lbr=3A_use_?= =?US-ASCII?Q?setup=5Fclear=5Fcpu=5Fcap_instead_of_clear=5Fcpu=5Fcap?= User-Agent: K-9 Mail for Android In-Reply-To: References: <20220718141123.136106-1-mlevitsk@redhat.com> <20220718141123.136106-2-mlevitsk@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On November 2, 2022 7:27:52 AM PDT, "Elliott, Robert (Servers)" wrote: > >> From: Paolo Bonzini >=2E=2E=2E >> (2) in particular holds even on bare metal=2E The kernel bug here is t= hat >> X86_FEATURE_AVX only tells you if the instructions are _present_, not i= f >> they are _usable_=2E Indeed, the XCR0 check is present for all other >> files in arch/x86/crypto, either instead or in addition to >> boot_cpu_has(X86_FEATURE_AVX)=2E >>=20 >> Maxim had sent a patch about a year ago to do it in aesni-intel-glue=2E= c >> but Dave told him to fix the dependencies instead >> (https://lore=2Ekernel=2Eorg/all/20211103124614=2E499580-1- >> mlevitsk@redhat=2Ecom/)=2E >> What do you think of applying that patch instead? > >Most of the x86 crypto modules using X86_FEATURE_AVX do check > cpu_has_xfeatures(XFEATURE_MASK_YMM, =2E=2E=2E > >so it's probably prudent to add it to the rest (or remove it everywhere >if it is not needed)=2E > >1=2E Currently checking XSAVE YMM: > aria_aesni_avx_glue > blake2s-glue > camellia_aesni_avx2_glue camellia_aesni_avx_glue > cast5_avx_glue cast6_avx_glue > chacha_glue > poly1305_glue > serpent_avx2_glue serpent_avx_glue > sha1_ssse3_glue sha256_ssse3_glue sha512_ssse3_glue > sm3_avx_glue > sm4_aesni_avx2_glue sm4_aesni_avx_glue > twofish_avx_glue > >Currently not checking XSAVE YMM: > aesni-intel_glue > curve25519-x86_64 > nhpoly1305-avx2-glue > polyval-clmulni_glue > >2=2E Similarly, modules using X86_FEATURE_AVX512F, X86_FEATURE_AVXX512VL >and/or X86_FEATURE_AVX512BW probably need to check XFEATURE_MASK_AVX512: > >Currently checking XSAVE AVX512: > blake2s-glue > poly1305_glue > >Currently not checking XSAVE AVX512: > chacha_glue > >3=2E Similarly, modules using X86_FEATURE_XMM2 probably need to >check XFEATURE_MASK_SSE: > >Currently checking XSAVE SSE: > aegis128-aesni-glue=20 > >Current not checking XSAVE SSE: > nhpoly1305-sse2_glue > serpent_sse2_glue > > > We have a dependency system for CPUID features=2E If you are going to do t= his (as opposed to "fixing" this in Qemu or just saying "don't do that, it = isn't a valid hardware configuration=2E"