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 C83E2E7AD57 for ; Tue, 3 Oct 2023 14:24:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240004AbjJCOYG (ORCPT ); Tue, 3 Oct 2023 10:24:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34324 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240001AbjJCOYD (ORCPT ); Tue, 3 Oct 2023 10:24:03 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC4EEC9 for ; Tue, 3 Oct 2023 07:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696343038; x=1727879038; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=A61WT88VnkzMQHVjtx4hwP9zSYAWPhVnWpEue6pcglA=; b=dKo/UiqQlR+Ha/6wY6wUbHdcV4K5R8GL1rOP9nAeTBMHP/vWlG2GP/de O0Ix4bxjKVlHwO1SYgGDHNf8V/C3nSVfgbidwqDG/fzrlpfMOs/wyf9tX dPdjQiEb3I9q7090twWHXiRr+aBqiHH1p216fsOC32H1UzmXejlR0c9Mw 8N+Qbq2y4UsF074Zn1zWYDA441SpJrOG9U7gHw67hx2XOg4XgVTfBGFsD FtF8X8hDG82Q/rMa1zrf526/y+Rew0Z5flR4qbLlsg39eDiVythTI7+it 7y7QyPyx0rYWklelObqsNn3Ag4Q2EVd1SZkZV3+q9C5qT+xsu5h96eAeq A==; X-IronPort-AV: E=McAfee;i="6600,9927,10852"; a="469163465" X-IronPort-AV: E=Sophos;i="6.03,197,1694761200"; d="scan'208";a="469163465" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Oct 2023 07:23:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10852"; a="866893090" X-IronPort-AV: E=Sophos;i="6.03,197,1694761200"; d="scan'208";a="866893090" Received: from ddiaz-mobl4.amr.corp.intel.com (HELO [10.209.57.36]) ([10.209.57.36]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Oct 2023 07:23:56 -0700 Message-ID: Date: Tue, 3 Oct 2023 07:23:56 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH] x86_64: test that userspace stack is in fact NX Content-Language: en-US To: Alexey Dobriyan Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , linux-kernel@vger.kernel.org, "H. Peter Anvin" References: <4b78a714-5ac3-4783-8256-1dda4673db01@p183> <1d5223b8-0275-619d-db1c-e2aaaddb173e@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/3/23 06:00, Alexey Dobriyan wrote: > On Mon, Oct 02, 2023 at 07:23:10AM -0700, Dave Hansen wrote: >> Basically, could you spend a moment in the changelog to talk about: >> >> 1. 32-bit kernels on NX hardware >> and >> 2. 64-bit kernels on non-NX hardware > > Sure. My logic whas that i386 is dead arch, but this test is easy to > port to i386, only 2 simple functions. I honestly don't feel strongly about it one way or the other. But whatever we do, let's explain it, please. > I don't want to parse /proc/cpuinfo. If someone knows they're shipping > NX-incapable hardware, just let them disable the test. Other than clearcpuid=nx, I don't _think_ we have any way to clear the X86_FEATURE_NX bit right now. That should mean that you can use regular old CPUID to see if the booted kernel supports NX. Perhaps something like what: tools/testing/selftests/x86/amx.c does with CPUID_LEAF1_ECX_XSAVE_MASK. That should be quite a bit easier than parsing /proc/cpuinfo. If someone does use clearcpuid, then I think it's perfectly reasonable to fail the selftest.