[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87muxmboxd.fsf@xmission.com>
Date: Sat, 28 Apr 2018 23:46:06 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Ingo Molnar <mingo@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [RFD] x86: The future of MPX
Ingo Molnar <mingo@...nel.org> writes:
> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
>> On Sat, Apr 28, 2018 at 2:18 AM Ingo Molnar <mingo@...nel.org> wrote:
>>
>> > I just tried the MPX testcases with the latest kernel:
>>
>> > deimos:~/tip/tools/testing/selftests/x86> ./mpx-mini-test_64
>>
>> They need to be run as root. They try to access
>>
>> /sys/kernel/debug/tracing/set_ftrace_pid
>> /sys/kernel/debug/tracing/trace
>>
>> and that's root-only.
>
> Indeed - but note that they are crashing as root as well here:
>
> root@...mos:/home/mingo/tip/tools/testing/selftests/x86# ./mpx-mini-test_64
> [...]
> Aborted (core dumped)
>
> ... because I don't even have /sys/kernel/debug/tracing/set_ftrace_pid... :-/
>
> That's despite having ftrace enabled.
>
> After some digging I found out that 'set_ftrace_pid' is dependent on
> CONFIG_FUNCTION_TRACING=y (not just CONFIG_TRACING=y), which I didn't
> have enabled on this kernel.
>
> After enabling it I got the 64-bit testcase to work:
>
> #
> ...
> ./mpx-mini-test_64 completed successfully
>
> But the 32-bit testcase is erroring out:
>
> root@...mos:/home/mingo/tip/tools/testing/selftests/x86# ./mpx-mini-test_32
> XSAVE is supported by HW & OS
> XSAVE processor supported state mask: 0x21f
> XSAVE OS supported state mask: 0x21f
> BNDREGS: size: 64 user: 1 supervisor: 0 aligned: 0
> BNDCSR: size: 64 user: 1 supervisor: 0 aligned: 0
> executing unmaptest
> mpx dig ( 1) complete, SUCCESS ( 0 / 0)
> #BR status == 2, missing bounds table,kernel should have handled!!
>
> v4.17-rc2 based kernel, so it should have the latest MPX code.
If you remove this which tree will this be going into?
I have some refactoring and cleanups of the x86 siginfo code I am
hoping to get in later this development cycle and part of that was
refactoring the mpx code so it works more like everything else.
If the codes away I can just that part of the patchset.
Eric
Powered by blists - more mailing lists