* Dave Hansen <dave.han...@linux.intel.com> wrote: > On 11/09/2017 10:12 PM, Ingo Molnar wrote: > > > > * Dave Hansen <dave.han...@linux.intel.com> wrote: > > > >> > >> From: Dave Hansen <dave.han...@linux.intel.com> > >> > >> 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 <dave.han...@linux.intel.com> > >> --- > >> > >> 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?
Latest Ubuntu, 17.10: triton:~/tip> cat /etc/os-release NAME="Ubuntu" VERSION="17.10 (Artful Aardvark)" triton:~/tip> apt-file find /usr/include/signal.h libc6-dev: /usr/include/signal.h triton:~/tip> dpkg -l libc6-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=======================================-========================-========================-==================================================================================== ii libc6-dev:amd64 2.26-0ubuntu2 amd64 GNU C Library: Development Libraries and Header Files > > 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. gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3) Thanks, Ingo