linux-kernel - Re: [RFC][PATCH 0/4] x86, mpx: Support larger address space (MAWA)

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170127081654.GA25162@gmail.com>
Date:   Fri, 27 Jan 2017 09:16:54 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Dave Hansen <dave.hansen@...ux.intel.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [RFC][PATCH 0/4] x86, mpx: Support larger address space (MAWA)


* Dave Hansen <dave.hansen@...ux.intel.com> wrote:

> Kirill is chugging right along getting his 5-level paging[1] patch set
> ready to be merged.  I figured I'd share an early draft of the MPX
> support that will to go along with it.
> 
> Background: there is a lot more detail about what bounds tables are in
> the changelog for fe3d197f843.  But, basically MPX bounds tables help
> us to store the ranges to which a pointer is allowed to point.  The
> tables are walked by hardware and they are indexed by the virtual
> address of the pointer being checked.
> 
> A larger virtual address space (from 5-level paging) means that we
> need larger tables.  5-level paging hardware includes a feature called
> MPX Address-Width Adjust (MAWA) that grows the bounds tables so they
> can address the new address space.  MAWA is controlled independently
> from the paging mode (via an MSR) so that old MPX binaries can run on
> new hardware and kernels supporting 5-level paging.
> 
> But, since userspace is responsible for allocating the table that is
> growing (the directory), we need to ensure that userspace and the
> kernel agree about the size of these tables and the kernel can set the
> MSR appropriately.
> 
> These are not quite ready to get applied anywhere, but I don't expect
> the basics to change unless folks have big problems with this.  The
> only big remaining piece of work is to update the MPX selftest code.
> 
> Dave Hansen (4):
>       x86, mpx: introduce per-mm MPX table size tracking
>       x86, mpx: update MPX to grok larger bounds tables
>       x86, mpx: extend MPX prctl() to pass in size of bounds directory
>       x86, mpx: context-switch new MPX address size MSR

On a related note, the MPX testcases seem to have gone from the 
tools/testing/selftests/x86/Makefile (possibly a merge mishap - the original 
commit adds it correctly), so they are not being built.

Plus I noticed that the pkeys testcases are producing a lot of noise:

triton:~/tip/tools/testing/selftests/x86> make
[...]
gcc -m64 -o protection_keys_64 -O2 -g -std=gnu99 -pthread -Wall  protection_keys.c -lrt -ldl
protection_keys.c: In function ‘setup_hugetlbfs’:
protection_keys.c:816:6: warning: unused variable ‘i’ [-Wunused-variable]
  int i;
      ^
protection_keys.c:815:6: warning: unused variable ‘validated_nr_pages’ [-Wunused-variable]
  int validated_nr_pages;
      ^
protection_keys.c: In function ‘test_pkey_syscalls_bad_args’:
protection_keys.c:1136:6: warning: unused variable ‘bad_flag’ [-Wunused-variable]
  int bad_flag = (PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE) + 1;
      ^
protection_keys.c: In function ‘test_pkey_alloc_exhaust’:
protection_keys.c:1153:16: warning: unused variable ‘init_val’ [-Wunused-variable]
  unsigned long init_val;
                ^
protection_keys.c:1152:16: warning: unused variable ‘flags’ [-Wunused-variable]
  unsigned long flags;
                ^
In file included from protection_keys.c:45:0:
pkey-helpers.h: In function ‘sigsafe_printf’:
pkey-helpers.h:41:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
   write(1, dprint_in_signal_buffer, len);
   ^
protection_keys.c: In function ‘dumpit’:
protection_keys.c:407:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^
protection_keys.c: In function ‘pkey_disable_set’:
protection_keys.c:68:5: warning: ‘orig_pkru’ may be used uninitialized in this function [-Wmaybe-uninitialized]
  if (!(condition)) {   \
     ^
protection_keys.c:465:6: note: ‘orig_pkru’ was declared here
  u32 orig_pkru;
      ^
[...]

Thanks,

	Ingo