From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755136AbdKJGlf (ORCPT ); Fri, 10 Nov 2017 01:41:35 -0500 Received: from mga01.intel.com ([192.55.52.88]:19506 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751218AbdKJGld (ORCPT ); Fri, 10 Nov 2017 01:41:33 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,373,1505804400"; d="scan'208";a="1082605" Subject: Re: [PATCH] x86, pkeys: update documentation about availability To: Ingo Molnar References: <20171109191249.B63E9BDB@viggo.jf.intel.com> <20171110061203.bxi7pn5ksk4yggg4@gmail.com> Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Andy Lutomirski , Thomas Gleixner , "H. Peter Anvin" From: Dave Hansen Message-ID: <249534a7-1f0e-7670-160c-dd48cc6d7b16@linux.intel.com> Date: Thu, 9 Nov 2017 22:41:32 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171110061203.bxi7pn5ksk4yggg4@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/09/2017 10:12 PM, Ingo Molnar wrote: > > * Dave Hansen wrote: > >> >> From: Dave Hansen >> >> Now that CPUs that implement Memory Protection Keys are publicly >> available we can be a bit less oblique about where it is available. >> >> Signed-off-by: Dave Hansen >> --- >> >> b/Documentation/x86/protection-keys.txt | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff -puN Documentation/x86/protection-keys.txt~pkeys-update Documentation/x86/protection-keys.txt >> --- a/Documentation/x86/protection-keys.txt~pkeys-update 2017-11-09 10:36:53.381467202 -0800 >> +++ b/Documentation/x86/protection-keys.txt 2017-11-09 10:43:15.527466249 -0800 >> @@ -1,5 +1,10 @@ >> -Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature >> -which will be found on future Intel CPUs. >> +Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature >> +which is found on Intel's Skylake "Scalable Processor" Server CPUs. >> +It will be avalable in future non-server parts. >> + >> +For anyone wishing to test or use this feature, it is available in >> +Amazon's EC2 C5 instances and is known to work there using an Ubuntu >> +17.04 image. >> >> Memory Protection Keys provides a mechanism for enforcing page-based >> protections, but without requiring modification of the page tables > > Could we please first fix the pkeys self-test? One of the testcases doesn't build > at all: > > gcc -m32 -o /home/mingo/tip/tools/testing/selftests/x86/protection_keys_32 -O2 -g -std=gnu99 -pthread -Wall -no-pie protection_keys.c -lrt -ldl -lm > In file included from /usr/include/signal.h:57:0, > from protection_keys.c:33: > protection_keys.c: In function ‘signal_handler’: > protection_keys.c:253:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ > before ‘.’ token > u64 si_pkey; That's odd. I build them all the time. I compiled it just now with 4.14-rc8 and gcc 4.8.4. I wonder if this is more fallout from the glibc headers getting updated to now contain pkey-related stuff. si_pkey might be getting #defined over for the siginfo si_pkey. What distro are you seeing this on? > plus, on a related note, the MPX testcase produces annoying warnings: > > gcc -m32 -o /home/mingo/tip/tools/testing/selftests/x86/mpx-mini-test_32 -O2 -g -std=gnu99 -pthread -Wall -no-pie mpx-mini-test.c -lrt -ldl -lm > mpx-mini-test.c: In function ‘insn_test_failed’: > mpx-mini-test.c:1406:3: warning: array subscript is above array bounds > [-Warray-bounds] > printf("bte[1]: %lx\n", bte->contents[1]); This is kinda a weird structure: > struct mpx_bt_entry { > union { > char x[MPX_BOUNDS_TABLE_ENTRY_SIZE_BYTES]; > unsigned long contents[1]; > }; > } __attribute__((packed)); I guess it should either be contents[0] or contents[MPX_BOUNDS_TABLE_ENTRY_SIZE_BYTE/sizeof(long)]. But, the warning is harmless at least. What gcc is this, btw? I must be behind the times.