Re: [PATCH v2] x86/fault: Decode and print #PF oops in human readable form

2018-12-07 Thread Andy Lutomirski
On Fri, Dec 7, 2018 at 2:14 PM Linus Torvalds wrote: > > On Fri, Dec 7, 2018 at 2:06 PM Sean Christopherson > wrote: > > > > Looking at it again, my own personal preference would be to swap the order > > of the #PF lines. > > Yeah, probably. > > Also: > > > [ 160.246820] BUG: unable to handle

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-07 Thread Andy Lutomirski
On Fri, Dec 7, 2018 at 1:26 PM Sean Christopherson wrote: > > On Fri, Dec 07, 2018 at 12:16:59PM -0800, Andy Lutomirski wrote: > > > > > > > On Dec 7, 2018, at 12:09 PM, Sean Christopherson > > > wrote: > > > > > >> On Fri

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-07 Thread Andy Lutomirski
> On Dec 7, 2018, at 12:09 PM, Sean Christopherson > wrote: > >> On Fri, Dec 07, 2018 at 11:23:10AM -0800, Andy Lutomirski wrote: >> >>>> On Dec 7, 2018, at 11:02 AM, Sean Christopherson >>>> wrote: >>>> >>>> On Fri,

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-07 Thread Andy Lutomirski
> On Dec 7, 2018, at 11:02 AM, Sean Christopherson > wrote: > >> On Fri, Dec 07, 2018 at 09:56:09AM -0800, Andy Lutomirski wrote: >> On Fri, Dec 7, 2018 at 8:51 AM Sean Christopherson >> wrote: >>> I like that the exit handler allows userspace to tra

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-07 Thread Andy Lutomirski
> On Dec 7, 2018, at 10:44 AM, Dave Hansen wrote: > >> On 12/7/18 10:15 AM, Jethro Beekman wrote: >> This is not sufficient to support the Fortanix SGX ABI calling >> convention, which was designed to be mostly compatible with the SysV >> 64-bit calling convention. The following registers

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-07 Thread Andy Lutomirski
On Fri, Dec 7, 2018 at 8:31 AM Dr. Greg wrote: > > On Thu, Dec 06, 2018 at 02:19:22PM -0800, Sean Christopherson wrote: > > Good morning, I hope the week is ending well for everyone. > > The audience for the issues that Sean is addressing are the groups > that have developed and are delivering an

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-07 Thread Andy Lutomirski
Thu, Dec 06, 2018 at 02:50:01PM -0800, Andy Lutomirski wrote: > > On Thu, Dec 6, 2018 at 2:19 PM Sean Christopherson > > wrote: > > > > > + > > > + /* > > > +* Invoke the caller's exit handler if one was provided. The > > >

Re: [RFC PATCH v2 4/4] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions

2018-12-06 Thread Andy Lutomirski
On Thu, Dec 6, 2018 at 2:19 PM Sean Christopherson wrote: > + > + /* > +* Invoke the caller's exit handler if one was provided. The return > +* value tells us whether to re-enter the enclave (EENTER or ERESUME) > +* or to return (EEXIT). > +*/ > + if

Re: [PATCH] x86/vdso: drop implicit common-page-size linker flag

2018-12-06 Thread Andy Lutomirski
cture, it's of questionable > use to implement in LLD. This patch resolves one of the issues towards > using LLD to link an x86_64 kernel. Sure. Acked-by: Andy Lutomirski

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Andy Lutomirski
On Thu, Dec 6, 2018 at 12:24 PM Linus Torvalds wrote: > > On Thu, Dec 6, 2018 at 11:07 AM Andy Lutomirski wrote: > > > > How do you like the attached patch? > > I agree with whoever thought it's odd that "read" is in lower case > when everything else is in up

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Andy Lutomirski
On Thu, Dec 6, 2018 at 10:15 AM Linus Torvalds wrote: > > On Wed, Dec 5, 2018 at 11:34 PM Ingo Molnar wrote: > > > > Yeah, so I don't like the overly long 'SUPERVISOR' and the somewhat > > inconsistent, sporadic handling of negatives. Here's our error code bits: > > > > /* > > * Page fault

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-06 Thread Andy Lutomirski
> On Dec 4, 2018, at 4:55 AM, Florian Weimer wrote: > > * Christian Brauner: > >>> On Mon, Dec 03, 2018 at 05:57:51PM +0100, Florian Weimer wrote: >>> * Christian Brauner: >>> Ok, I finally have access to source code again. Scratch what I said above! I looked at the code and tested it.

Re: [PATCH v7 13/14] module: Do not set nx for module memory before freeing

2018-12-06 Thread Andy Lutomirski
On Wed, Dec 5, 2018 at 12:52 AM Nadav Amit wrote: > > When module memory is about to be freed, there is no apparent reason to > make it (and its data) executable, but that's exactly what is done > today. This is not efficient and not secure. > > There are various theories why it was done, but

Re: [RFC PATCH 3/4] x86/traps: Attempt to fixup exceptions in vDSO before signaling

2018-12-06 Thread Andy Lutomirski
On Thu, Dec 6, 2018 at 10:22 AM Dave Hansen wrote: > > On 12/5/18 3:20 PM, Sean Christopherson wrote: > > @@ -223,6 +224,10 @@ do_trap_no_signal(struct task_struct *tsk, int trapnr, > > const char *str, > > tsk->thread.error_code = error_code; > > tsk->thread.trap_nr = trapnr; > > >

Re: [RFC PATCH 2/4] x86/fault: Attempt to fixup unhandled #PF in vDSO before signaling

2018-12-06 Thread Andy Lutomirski
On Thu, Dec 6, 2018 at 10:17 AM Dave Hansen wrote: > > > #define CREATE_TRACE_POINTS > > #include > > @@ -928,6 +929,9 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned > > long error_code, > > if (address >= TASK_SIZE_MAX) > > error_code |=

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Andy Lutomirski
> On Dec 6, 2018, at 8:47 AM, Ingo Molnar wrote: > > > * Andy Lutomirski wrote: > >>> vs. (with SGX added as 'G' for testing purposes) >>> >>> [0.158849] #PF error code(0001): +P !W !U !S !I !K !G >>> [0.159292] #PF error code(

Re: [PATCH] x86/mm/fault: Streamline the fault error_code decoder some more

2018-12-06 Thread Andy Lutomirski
> On Dec 6, 2018, at 7:53 AM, Sean Christopherson > wrote: > >> On Thu, Dec 06, 2018 at 08:34:09AM +0100, Ingo Molnar wrote: >> I like your '!' idea, but with a further simplification: how about using >> '-/+' differentiation and a single character and a fixed-length message. >> >> The

Re: [RFC PATCH 4/4] x86/vdso: Add __vdso_sgx_eenter() to wrap SGX enclave transitions

2018-12-05 Thread Andy Lutomirski
er, i.e. RAX, back to userspace so that the caller can know > whether the fault occurred in the enclave or if it occurred on EENTER. > A fault on EENTER generally means the enclave has died and needs to be > restarted. > > Suggested-by: Andy Lutomirski > Cc: Andy Lutomirski &

Re: [PATCH v2 0/4] Static calls

2018-12-05 Thread Andy Lutomirski
>> On Dec 5, 2018, at 7:04 AM, Josh Poimboeuf wrote: > > >> Anyway, I have a new objection to Josh’s create_gap proposal: what on >> Earth will kernel CET do to it? Maybe my longjmp-like hack is >> actually better. > > Does CET even care about iret? I assumed it didn't. If it does, your >

Re: [PATCH 2/6] __wr_after_init: write rare for static allocation

2018-12-05 Thread Andy Lutomirski
mset(): write rare counterpart of memset() > - wr_memcpy(): write rare counterpart of memcpy() > - wr_assign(): write rare counterpart of the assignment ('=') operator > - wr_rcu_assign_pointer(): write rare counterpart of rcu_assign_pointer() > > The implementation is based on code fr

Re: [PATCH 6/5] x86/fault: Clean up the page fault oops decoder a bit

2018-12-05 Thread Andy Lutomirski
> + err_str_append(error_code, err_txt, X86_PF_INSTR, "[INSTR]", NULL); > + err_str_append(error_code, err_txt, X86_PF_PK,"[PK]" , NULL); > + err_str_append(error_code, err_txt, X86_PF_WRITE | X86_PF_INSTR, NULL, > +

Re: [PATCH 1/2] vmalloc: New flag for flush before releasing pages

2018-12-04 Thread Andy Lutomirski
> On Dec 4, 2018, at 3:52 PM, Edgecombe, Rick P > wrote: > >> On Tue, 2018-12-04 at 12:09 -0800, Andy Lutomirski wrote: >> On Tue, Dec 4, 2018 at 12:02 PM Edgecombe, Rick P >> wrote: >>> >>>> On Tue, 2018-12-04 at 16:03 +, Will Deaco

Re: [PATCH v2 0/4] Static calls

2018-12-04 Thread Andy Lutomirski
> On Dec 4, 2018, at 3:08 PM, Steven Rostedt wrote: > > > Where did this end up BTW? > > I know that there's controversy about the > CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the > CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the > v1 patch 0

Re: [PATCH v2 2/4] x86/vdso: Remove a stale/misleading comment from the linker script

2018-12-04 Thread Andy Lutomirski
nder that they don't need to be included in the final vDSO image, > i.e. someone may want to take another stab at zapping/stripping the > unneeded sections. Acked-by: Andy Lutomirski

Re: [PATCH v2 1/4] x86/vdso: Remove obsolete "fake section table" reservation

2018-12-04 Thread Andy Lutomirski
> > Removing the fake section table placeholder zaps a whopping 0x340 bytes > from the 64-bit vDSO image, which drops the current image's size to > under 4k, i.e. reduces the effective size of the userspace vDSO mapping > by a full page. Acked-by: Andy Lutomirski

Re: [PATCH 6/5] x86/fault: Clean up the page fault oops decoder a bit

2018-12-04 Thread Andy Lutomirski
On Tue, Dec 4, 2018 at 11:52 AM Sean Christopherson wrote: > > On Tue, Dec 04, 2018 at 11:47:10AM -0800, Andy Lutomirski wrote: > > On Tue, Dec 4, 2018 at 11:34 AM Sean Christopherson > > wrote: > > > > > > On Tue, Dec 04, 2018 at 11:22:25AM -0800, Andy Luto

Re: [PATCH 6/5] x86/fault: Clean up the page fault oops decoder a bit

2018-12-04 Thread Andy Lutomirski
On Tue, Dec 4, 2018 at 11:34 AM Sean Christopherson wrote: > > On Tue, Dec 04, 2018 at 11:22:25AM -0800, Andy Lutomirski wrote: > > On Tue, Nov 27, 2018 at 7:32 AM Sean Christopherson > > wrote: > > > diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c > > &

Re: [PATCH 1/2] x86/vdso: Remove obsolete "fake section table" reservation

2018-12-04 Thread Andy Lutomirski
On Tue, Dec 4, 2018 at 11:28 AM Sean Christopherson wrote: > > On Tue, Dec 04, 2018 at 10:58:51AM -0800, Andy Lutomirski wrote: > > On Tue, Dec 4, 2018 at 10:29 AM Sean Christopherson > > wrote: > > > > > > On Tue, Dec 04, 2018 at 10:22:39AM -0800, Sean Chris

Re: [PATCH 6/5] x86/fault: Clean up the page fault oops decoder a bit

2018-12-04 Thread Andy Lutomirski
On Tue, Nov 27, 2018 at 7:32 AM Sean Christopherson wrote: > > On Thu, Nov 22, 2018 at 09:41:19AM +0100, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > > > One of Linus' favorite hobbies seems to be looking at OOPSes and > > > decoding th

Re: [PATCH 2/2] x86/vdso: Remove a stale/misleading comment from the linker script

2018-12-04 Thread Andy Lutomirski
nder that they don't need to be included in the final vDSO image, > i.e. someone may want to take another stab at zapping/stripping the > unneeded sections. Acked-by: Andy Lutomirski

Re: [PATCH 1/2] x86/vdso: Remove obsolete "fake section table" reservation

2018-12-04 Thread Andy Lutomirski
> > > Removing the fake section table placeholder zaps a whopping 0x340 bytes > > > from the 64-bit vDSO image, which drops the current image's size to > > > under 4k, i.e. reduces the effective size of the userspace vDSO mapping > > > by a full page. > > >

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-01 Thread Andy Lutomirski
On Sat, Dec 1, 2018 at 4:07 PM Eric W. Biederman wrote: > > Andy Lutomirski writes: > > >> On Dec 1, 2018, at 7:28 AM, Eric W. Biederman > >> wrote: > >> > >> > >> It just occurs to me that the simple way to implemen

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-12-01 Thread Andy Lutomirski
> On Dec 1, 2018, at 7:28 AM, Eric W. Biederman wrote: > > > It just occurs to me that the simple way to implement > procfd_sigqueueinfo info is like: > > int copy_siginfo_from_user_any(kernel_siginfo_t *info, siginfo_t *uinfo) > { > #ifdef CONFIG_COMPAT >if (in_compat_syscall) >

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-30 Thread Andy Lutomirski
On Fri, Nov 30, 2018 at 2:10 PM Arnd Bergmann wrote: > > On Fri, Nov 30, 2018 at 5:36 PM Andy Lutomirski wrote: > > > > On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote: > > > siginfo_t as it is now still has a number of other downsides, and Andy in > >

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-30 Thread Andy Lutomirski
On Fri, Nov 30, 2018 at 3:40 PM Christian Brauner wrote: > > On December 1, 2018 12:12:53 PM GMT+13:00, Arnd Bergmann > wrote: > >On Sat, Dec 1, 2018 at 12:05 AM Daniel Colascione > >wrote: > >> On Fri, Nov 30, 2018 at 2:26 PM Christian Brauner > > wrote: > >> > On December 1, 2018 11:09:58 AM

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Andy Lutomirski
On Fri, Nov 30, 2018 at 12:28 PM Steven Rostedt wrote: > > On Fri, 30 Nov 2018 12:18:33 -0800 > Andy Lutomirski wrote: > > > Or we could replace that IPI with x86's bona fide serialize-all-cpus > > primitive and then we can just retry instead of emulating. It's a >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Andy Lutomirski
On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds wrote: > > On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf wrote: > > > > AFAICT, all the other proposed options seem to have major issues. > > I still absolutely detest this patch, and in fact it got worse from > the test of the config variable. >

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-30 Thread Andy Lutomirski
On Thu, Nov 29, 2018 at 12:24 PM Josh Poimboeuf wrote: > > > Alternatively, we could actually emulate call instructions like this: > > > > void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...) > > { > > struct pt_regs ptregs_copy = *regs; > > barrier(); > > *(unsigned long

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-30 Thread Andy Lutomirski
On Fri, Nov 30, 2018 at 3:41 AM Arnd Bergmann wrote: > siginfo_t as it is now still has a number of other downsides, and Andy in > particular didn't like the idea of having three new variants on x86 > (depending on how you count). His alternative suggestion of having > a single syscall entry

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
gt; On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote: > > > > > > > > (like pointing IP at a stub that retpolines to the target by reading > > > > > the function pointer, a la the unoptimizable version), then okay, I > > > > > gues

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 11:55 AM, Christian Brauner wrote: > >> On Thu, Nov 29, 2018 at 11:22:58AM -0800, Andy Lutomirski wrote: >>> On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner >>> wrote: >>> >>>> On November 30, 2018

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
On Thu, Nov 29, 2018 at 11:25 AM Linus Torvalds wrote: > > On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt wrote: > > > > But then we need to implement all numbers of parameters. > > Oh, I agree, it's nasty. > > But it's actually a nastiness that we've solved before. In particular, > with the

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds wrote: > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds > wrote: > > > > In contrast, if the call was wrapped in an inline asm, we'd *know* the > > compiler couldn't turn a "call wrapper(%rip)" into anything else. > > Actually, I think I have a

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-29 Thread Andy Lutomirski
On Thu, Nov 29, 2018 at 11:17 AM Christian Brauner wrote: > > On November 30, 2018 5:54:18 AM GMT+13:00, Andy Lutomirski > wrote: > > > > > >> On Nov 29, 2018, at 4:28 AM, Florian Weimer > >wrote: > >> > >> Disclaimer: I'm looking

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 9:50 AM, Linus Torvalds > wrote: > >> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt wrote: >> >> Well, the current method (as Jiri mentioned) did get the OK from at >> least Intel (and that was with a lot of arm twisting to do so). > > Guys, when the comparison is

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 9:45 AM, Josh Poimboeuf wrote: > >> On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote: >> >>> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote: >>> >>> On Thu, 29 Nov 2018 12:20:00 -0500 >>> Ste

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 9:21 AM, Steven Rostedt wrote: > > On Thu, 29 Nov 2018 12:20:00 -0500 > Steven Rostedt wrote: > > >> r8 = return address >> r9 = function to call >> > > Bad example, r8 and r9 are args, but r10 and r11 are available. > > -- Steve > >>push r8 >>jmp *r9 >>

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 9:29 AM, Linus Torvalds > wrote: > > On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski wrote: >>> >>> - just restart the instruction (with the suggested "ptregs->rip --") >>> >>> - to avoid any "o

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 9:07 AM, Peter Zijlstra wrote: > > On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote: >>> On Nov 29, 2018, at 8:50 AM, Linus Torvalds >>> wrote: > >>> So no. Do *not* try to change %rsp on the stack in t

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 8:50 AM, Linus Torvalds > wrote: > >> On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf wrote: >> >> This seems to work... >> >> + .if \create_gap == 1 >> + .rept 6 >> + pushq 5*8(%rsp) >> + .endr >> + .endif >> + >> -idtentry int3

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 8:49 AM, Peter Zijlstra wrote: > > On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote: >>> can't we 'fix' that again? The alternative is moving that IRET-frame and >>> fixing everything up, which is going to be fragile, ugly and such >>> things more. > >>

Re: [PATCH v2] signal: add procfd_signal() syscall

2018-11-29 Thread Andy Lutomirski
> # x32-specific system call numbers start at 512 to avoid cache impact >> @@ -386,3 +387,4 @@ >> 545x32execveat__x32_compat_sys_execveat/ptregs >> 546x32preadv2__x32_compat_sys_preadv64v2 >> 547x32pwritev2 __x32_compat_

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-29 Thread Andy Lutomirski
> On Nov 29, 2018, at 1:42 AM, Peter Zijlstra wrote: > > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote: > >>>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data) >>>> +{ >>>&g

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-28 Thread Andy Lutomirski
On Wed, Nov 28, 2018 at 7:24 PM Andy Lutomirski wrote: > > > On Nov 28, 2018, at 6:06 PM, Nadav Amit wrote: > > >> On Nov 28, 2018, at 5:40 PM, Andy Lutomirski wrote: > >> > >>> On Wed, Nov 28, 2018 at 4:38 PM Josh Poimboeuf > >>> wrote:

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-28 Thread Andy Lutomirski
> On Nov 27, 2018, at 12:43 AM, Peter Zijlstra wrote: > >> On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote: >> >> Yeah, that's probably better. I assume you also mean that we would have >> all text_poke_bp() users create a handler callback? That way the >> interface is clear and

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-28 Thread Andy Lutomirski
On Nov 28, 2018, at 6:06 PM, Nadav Amit wrote: >> On Nov 28, 2018, at 5:40 PM, Andy Lutomirski wrote: >> >>> On Wed, Nov 28, 2018 at 4:38 PM Josh Poimboeuf wrote: >>> On Wed, Nov 28, 2018 at 07:34:52PM +, Nadav Amit wrote: >>>>> On No

Re: [RFC PATCH 0/5] x86: dynamic indirect call promotion

2018-11-28 Thread Andy Lutomirski
On Wed, Nov 28, 2018 at 4:38 PM Josh Poimboeuf wrote: > > On Wed, Nov 28, 2018 at 07:34:52PM +, Nadav Amit wrote: > > > On Nov 28, 2018, at 8:08 AM, Josh Poimboeuf wrote: > > > > > > On Wed, Oct 17, 2018 at 05:54:15PM -0700, Nadav Amit wrote: > > >> This RFC introduces indirect call

Re: [PATCH v4 1/2] ptrace: save the type of syscall-stop in ptrace_message

2018-11-28 Thread Andy Lutomirski
On Wed, Nov 28, 2018 at 2:11 PM Dmitry V. Levin wrote: > > On Wed, Nov 28, 2018 at 06:23:46PM +0300, Dmitry V. Levin wrote: > > On Wed, Nov 28, 2018 at 03:20:06PM +0100, Oleg Nesterov wrote: > > > On 11/28, Dmitry V. Levin wrote: > > > > On Wed, Nov 28, 2018 at 02:49:14PM +0100, Oleg Nesterov

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-28 Thread Andy Lutomirski
On Tue, Nov 27, 2018 at 12:55 AM Dr. Greg wrote: > Since the thread has become a bit divergent I wanted to note that we > have offered a proposal for a general policy management framework > based on MRSIGNER values. This framework is consistent with the SGX > security model, ie. cryptographic

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-27 Thread Andy Lutomirski
> On Nov 27, 2018, at 8:41 AM, Jarkko Sakkinen > wrote: > >> On Tue, Nov 27, 2018 at 02:55:33AM -0600, Dr. Greg wrote: >> Since the thread has become a bit divergent I wanted to note that we >> have offered a proposal for a general policy management framework >> based on MRSIGNER values.

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Andy Lutomirski
On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf wrote: > > On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote: > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote: > > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c > > > index

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-26 Thread Andy Lutomirski
On Mon, Nov 26, 2018 at 3:00 AM Dr. Greg wrote: > > On Sun, Nov 25, 2018 at 04:37:00PM -0800, Andy Lutomirski wrote: > > > Bah, I hit send on a partially written draft. I???ll try again soon. > > > > --Andy > > Your first issue seems to be complete so I will r

Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64

2018-11-26 Thread Andy Lutomirski
On Mon, Nov 26, 2018 at 8:11 AM Ard Biesheuvel wrote: > > On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra wrote: > > > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote: > > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE > > > +void arch_static_call_defuse_tramp(void *site, void *tramp) >

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-25 Thread Andy Lutomirski
Bah, I hit send on a partially written draft. I’ll try again soon. --Andy > On Nov 25, 2018, at 1:59 PM, Andy Lutomirski wrote: > > > >> On Nov 25, 2018, at 10:55 AM, Dr. Greg wrote: >> > >> >> >> The notion of a launch enclave is critical

Re: [patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm()

2018-11-25 Thread Andy Lutomirski
> On Nov 25, 2018, at 2:20 PM, Thomas Gleixner wrote: > > On Sun, 25 Nov 2018, Andi Kleen wrote: > >>> The current check whether two tasks belong to the same context is using the >>> tasks context id. While correct, it's simpler to use the mm pointer because >>> it allows to mangle the

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-25 Thread Andy Lutomirski
>> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen >> wrote: >> >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: >>>> At a high level, addressing these issues is strai

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Andy Lutomirski
> On Nov 23, 2018, at 11:44 AM, Linus Torvalds > wrote: > >> On Fri, Nov 23, 2018 at 10:39 AM Andy Lutomirski wrote: >> >> What is memcpy_to_io even supposed to do? I’m guessing it’s defined as >> something like “copy this data to IO space using at most l

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-23 Thread Andy Lutomirski
> On Nov 23, 2018, at 10:42 AM, Linus Torvalds > wrote: > > On Fri, Nov 23, 2018 at 8:36 AM Linus Torvalds > wrote: >> >> Let me write a generic routine in lib/iomap_copy.c (which already does >> the "user specifies chunk size" cases), and hook it up for x86. > > Something like this? > >

Re: [PATCH v4 2/4] namei: O_BENEATH-style path resolution flags

2018-11-23 Thread Andy Lutomirski
> On Nov 23, 2018, at 5:10 AM, Jürg Billeter wrote: > > Hi Aleksa, > >> On Tue, 2018-11-13 at 01:26 +1100, Aleksa Sarai wrote: >> * O_BENEATH: Disallow "escapes" from the starting point of the >> filesystem tree during resolution (you must stay "beneath" the >> starting point at all times).

Re: [PATCH v5] x86/fsgsbase/64: Fix the base write helper functions

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 4:42 PM Andy Lutomirski wrote: > > On Thu, Nov 22, 2018 at 12:56 PM Ingo Molnar wrote: > > > > > > * Andy Lutomirski wrote: > > > > > On Fri, Nov 16, 2018 at 3:27 PM Chang S. Bae > > > wrote: > > > > > &

Re: [PATCH v5] x86/fsgsbase/64: Fix the base write helper functions

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 12:56 PM Ingo Molnar wrote: > > > * Andy Lutomirski wrote: > > > On Fri, Nov 16, 2018 at 3:27 PM Chang S. Bae > > wrote: > > > > > > The helper functions that purport to write the base should just write it > > > on

Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 11:15 AM Dmitry V. Levin wrote: > > On Thu, Nov 22, 2018 at 06:55:29AM -0800, Andy Lutomirski wrote: > > On Wed, Nov 21, 2018 at 3:56 PM Dmitry V. Levin wrote: > > > On Wed, Nov 21, 2018 at 02:56:57PM -0800, Andy Lutomirski wrote: &g

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 3:12 AM Dr. Greg wrote: > In addition, we are not confident > the driver will be useful to anything other then server class hardware > and will be incapable of supporting virtually all of the existing SGX > hardware in the field. I forgot to mention: I have a plain old

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 9:53 AM Linus Torvalds wrote: > > On Thu, Nov 22, 2018 at 9:36 AM David Laight wrote: > > > > The other problem with the ERMS copy is that it gets used > > for copy_to/from_io() - and the 'rep movsb' on uncached > > locations has to do byte copies. > > Ugh. I thought we

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 8:56 AM Linus Torvalds wrote: > > On Thu, Nov 22, 2018 at 2:32 AM Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > > > > Random patch (with my "asm goto" hack included) attached, in case > > > people want to play with it. > > > > Doesn't even look all that hacky to

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 3:12 AM Dr. Greg wrote: > > On Tue, Nov 20, 2018 at 02:04:42PM +0200, Jarkko Sakkinen wrote: > > Good morning to everyone, Happy Thanksgiving to those who are > celebrating the holiday. > > > On Mon, Nov 19, 2018 at 08:59:24AM -0800, Andy Lutomirs

Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request

2018-11-22 Thread Andy Lutomirski
On Wed, Nov 21, 2018 at 3:56 PM Dmitry V. Levin wrote: > > On Wed, Nov 21, 2018 at 02:56:57PM -0800, Andy Lutomirski wrote: > > Please cc linux-...@vger.kernel.org for future versions. > > > > On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova wrote: > > >

Re: [tip:x86/mm] x86/fault: Clean up the page fault oops decoder a bit

2018-11-22 Thread Andy Lutomirski
On Thu, Nov 22, 2018 at 2:13 AM tip-bot for Ingo Molnar wrote: > > Commit-ID: a2aa52ab16efbee40ad118ebac4a5e438f5b43ee > Gitweb: > https://git.kernel.org/tip/a2aa52ab16efbee40ad118ebac4a5e438f5b43ee > Author: Ingo Molnar > AuthorDate: Thu, 22 Nov 2018 09:34:03 +0100 > Committer: Ingo

[tip:x86/mm] x86/vsyscall/64: Use X86_PF constants in the simulated #PF error code

2018-11-22 Thread tip-bot for Andy Lutomirski
Commit-ID: af2ebdcf044039e89da3cd44c0f04dea317020c5 Gitweb: https://git.kernel.org/tip/af2ebdcf044039e89da3cd44c0f04dea317020c5 Author: Andy Lutomirski AuthorDate: Wed, 21 Nov 2018 15:11:26 -0800 Committer: Ingo Molnar CommitDate: Thu, 22 Nov 2018 09:24:27 +0100 x86/vsyscall/64: Use

[tip:x86/mm] x86/oops: Show the correct CS value in show_regs()

2018-11-22 Thread tip-bot for Andy Lutomirski
Commit-ID: d38bc89c72e7235ac889ae64fe7828e2e61a18af Gitweb: https://git.kernel.org/tip/d38bc89c72e7235ac889ae64fe7828e2e61a18af Author: Andy Lutomirski AuthorDate: Wed, 21 Nov 2018 15:11:24 -0800 Committer: Ingo Molnar CommitDate: Thu, 22 Nov 2018 09:23:01 +0100 x86/oops: Show

[tip:x86/mm] x86/fault: Decode page fault OOPSes better

2018-11-22 Thread tip-bot for Andy Lutomirski
Commit-ID: a1a371c468f7238b7826fde55786b02377faf8e2 Gitweb: https://git.kernel.org/tip/a1a371c468f7238b7826fde55786b02377faf8e2 Author: Andy Lutomirski AuthorDate: Wed, 21 Nov 2018 15:11:25 -0800 Committer: Ingo Molnar CommitDate: Thu, 22 Nov 2018 09:24:28 +0100 x86/fault: Decode page

[tip:x86/mm] x86/fault: Don't try to recover from an implicit supervisor access

2018-11-22 Thread tip-bot for Andy Lutomirski
Commit-ID: ebb53e2597e2dc7637ab213df006e99681b6ee25 Gitweb: https://git.kernel.org/tip/ebb53e2597e2dc7637ab213df006e99681b6ee25 Author: Andy Lutomirski AuthorDate: Wed, 21 Nov 2018 15:11:23 -0800 Committer: Ingo Molnar CommitDate: Thu, 22 Nov 2018 09:23:00 +0100 x86/fault: Don't try

[tip:x86/mm] x86/fault: Remove sw_error_code

2018-11-22 Thread tip-bot for Andy Lutomirski
Commit-ID: 0ed32f1aa66ee758e6c8164f549f7ff9d399a20e Gitweb: https://git.kernel.org/tip/0ed32f1aa66ee758e6c8164f549f7ff9d399a20e Author: Andy Lutomirski AuthorDate: Wed, 21 Nov 2018 15:11:22 -0800 Committer: Ingo Molnar CommitDate: Thu, 22 Nov 2018 09:22:59 +0100 x86/fault: Remove

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-21 Thread Andy Lutomirski
expected > future-write seal now active > write failed as expected due to future-write seal > map 2 prot-write failed as expected due to seal > : Permission denied > map 3 prot-read passed as expected > > [j...@joelfernandes.org: make F_SEAL_FUTURE_WRITE seal more robust]

[PATCH v2 0/5] x86/fault: #PF improvements, mostly related to USER bit

2018-11-21 Thread Andy Lutomirski
material changes are that 'x86/fault: Check user_mode(regs) when validating a stack extension' is gone because the code it fixed has been deleted and that 'x86/fault: Remove sw_error_code' lost the hunk that changed the same code. Andy Lutomirski (5): x86/fault: Remove sw_error_code x86

[PATCH v2 3/5] x86/oops: Show the correct CS value in show_regs()

2018-11-21 Thread Andy Lutomirski
n implicit supervisor access from user mode. Signed-off-by: Andy Lutomirski --- arch/x86/kernel/process_64.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c index 0e0b4288a4b2..2b8e6324fa20 100644 --- a/arch/x86/kernel/pr

[PATCH v2 5/5] x86/vsyscall/64: Use X86_PF constants in the simulated #PF error code

2018-11-21 Thread Andy Lutomirski
Rather than hardcoding 6 with a comment, use the defined constants. Signed-off-by: Andy Lutomirski --- arch/x86/entry/vsyscall/vsyscall_64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c index

[PATCH v2 1/5] x86/fault: Remove sw_error_code

2018-11-21 Thread Andy Lutomirski
All of the fault handling code now corrently checks user_mode(regs) as needed, and nothing depends on the X86_PF_USER bit being munged. Get rid of the sw_error code and use hw_error_code everywhere. Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 50

[PATCH v2 2/5] x86/fault: Don't try to recover from an implicit supervisor access

2018-11-21 Thread Andy Lutomirski
This avoids a situation in which we attempt to apply various fixups that are not intended to handle implicit supervisor accesses from user mode if we screw up in away that causes this type of fault. Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 10 ++ 1 file changed, 10

[PATCH v2 4/5] x86/fault: Decode page fault OOPSes better

2018-11-21 Thread Andy Lutomirski
Hardware name: ... RIP: 0033:0x401454 Signed-off-by: Andy Lutomirski --- arch/x86/mm/fault.c | 84 + 1 file changed, 84 insertions(+) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index ca38bd0472f2..f5efbdba2b6d 100644 --- a/arch/x86/mm

Re: [RFC PATCH v2] ptrace: add PTRACE_GET_SYSCALL_INFO request

2018-11-21 Thread Andy Lutomirski
Please cc linux-...@vger.kernel.org for future versions. On Wed, Nov 21, 2018 at 7:58 AM Elvira Khabirova wrote: > > struct ptrace_syscall_info { > __u8 op; /* 0 for entry, 1 for exit */ Can you add proper defines, like: #define PTRACE_SYSCALL_ENTRY 0 #define PTRACE_SYSCALL_EXIT 1

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-21 Thread Andy Lutomirski
On Wed, Nov 21, 2018 at 10:44 AM Linus Torvalds wrote: > > On Wed, Nov 21, 2018 at 10:26 AM Andy Lutomirski wrote: > > > > Can we maybe use this as an excuse to ask for some reasonable instructions > > to access user memory? > > I did that long ago. It's why we ha

Re: [PATCH] x86: only use ERMS for user copies for larger sizes

2018-11-21 Thread Andy Lutomirski
> On Nov 21, 2018, at 11:04 AM, Jens Axboe wrote: > >> On 11/21/18 10:27 AM, Linus Torvalds wrote: >>> On Wed, Nov 21, 2018 at 5:45 AM Paolo Abeni wrote: >>> >>> In my experiments 64 bytes was the break even point for all the CPUs I >>> had handy, but I guess that may change with other

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-20 Thread Andy Lutomirski
> On Nov 20, 2018, at 1:47 PM, Joel Fernandes wrote: > >> On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote: >> >>> On Nov 20, 2018, at 1:07 PM, Stephen Rothwell wrote: >>> >>> Hi Joel, >>> >>>>

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-20 Thread Andy Lutomirski
> On Nov 20, 2018, at 1:07 PM, Stephen Rothwell wrote: > > Hi Joel, > >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes >> wrote: >> >>> On Tue, Nov 20, 2018 at 07:13:17AM -0800, Andy Lutomirski wrote: >>> On Mon, Nov 19, 20

Re: Cleaning up numbering for new x86 syscalls?

2018-11-20 Thread Andy Lutomirski
On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote: > > * Andy Lutomirski: > > > 5. Adjust the scripts so that we only have to wire up new syscalls > > once. They'll have a nr above 1024, and they'll have the same nr on > > all x86 variants. > > Is there a su

Re: RFC: userspace exception fixups

2018-11-20 Thread Andy Lutomirski
On Tue, Nov 20, 2018 at 2:11 AM Jarkko Sakkinen wrote: > > On Mon, Nov 19, 2018 at 09:00:08AM -0800, Andy Lutomirski wrote: > > On Mon, Nov 19, 2018 at 8:02 AM Jarkko Sakkinen > > wrote: > > > > > > On Mon, Nov 19, 2018 at 07:29:36AM -0800, Andy Lutomirski wro

Re: [PATCH -next 1/2] mm/memfd: make F_SEAL_FUTURE_WRITE seal more robust

2018-11-20 Thread Andy Lutomirski
ndy [2]. > > [1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/ > [2] > https://lore.kernel.org/lkml/69ce06cc-e47c-4992-848a-66eb23ee6...@amacapital.net/ > > Suggested-by: Andy Lutomirski > Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to m

[tip:x86/mm] x86/fault: Don't set thread.cr2, etc before OOPSing

2018-11-20 Thread tip-bot for Andy Lutomirski
Commit-ID: 1ad33f5aec20f53785dbad44c6fb3b204aefd921 Gitweb: https://git.kernel.org/tip/1ad33f5aec20f53785dbad44c6fb3b204aefd921 Author: Andy Lutomirski AuthorDate: Mon, 19 Nov 2018 14:45:32 -0800 Committer: Ingo Molnar CommitDate: Tue, 20 Nov 2018 08:44:30 +0100 x86/fault: Don't set

[tip:x86/mm] x86/fault: Make error_code sanitization more robust

2018-11-20 Thread tip-bot for Andy Lutomirski
Commit-ID: e49d3cbef0176c182b86206185f137a87f16ab91 Gitweb: https://git.kernel.org/tip/e49d3cbef0176c182b86206185f137a87f16ab91 Author: Andy Lutomirski AuthorDate: Mon, 19 Nov 2018 14:45:31 -0800 Committer: Ingo Molnar CommitDate: Tue, 20 Nov 2018 08:44:29 +0100 x86/fault: Make

  1   2   3   4   5   6   7   8   9   10   >