|
Message-ID: <CAMGffEm3bRrshMftdpC4cTNppQuFUPyOniE3zZL7PJRinbVVfw@mail.gmail.com> Date: Tue, 6 Mar 2018 17:11:20 +0100 From: Jinpu Wang <jinpu.wang@...fitbricks.com> To: Jiri Slaby <jslaby@...e.cz> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org, stable <stable@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Dan Williams <dan.j.williams@...el.com>, Thomas Gleixner <tglx@...utronix.de>, linux-arch@...r.kernel.org, kernel-hardening@...ts.openwall.com, Andy Lutomirski <luto@...nel.org>, alan@...ux.intel.com, David Woodhouse <dwmw@...zon.co.uk>, Jan Beulich <JBeulich@...e.com> Subject: Re: [PATCH 4.4 178/193] x86/syscall: Sanitize syscall table de-references under speculation On Tue, Mar 6, 2018 at 3:21 PM, Jiri Slaby <jslaby@...e.cz> wrote: > On 02/23/2018, 07:26 PM, Greg Kroah-Hartman wrote: >> 4.4-stable review patch. If anyone has any objections, please let me know. >> >> ------------------ >> >> From: Dan Williams <dan.j.williams@...el.com> >> >> (cherry picked from commit 2fbd7af5af8665d18bcefae3e9700be07e22b681) >> >> The syscall table base is a user controlled function pointer in kernel >> space. Use array_index_nospec() to prevent any out of bounds speculation. >> >> While retpoline prevents speculating into a userspace directed target it >> does not stop the pointer de-reference, the concern is leaking memory >> relative to the syscall table base, by observing instruction cache >> behavior. >> >> Reported-by: Linus Torvalds <torvalds@...ux-foundation.org> >> Signed-off-by: Dan Williams <dan.j.williams@...el.com> >> Signed-off-by: Thomas Gleixner <tglx@...utronix.de> >> Cc: linux-arch@...r.kernel.org >> Cc: kernel-hardening@...ts.openwall.com >> Cc: gregkh@...uxfoundation.org >> Cc: Andy Lutomirski <luto@...nel.org> >> Cc: alan@...ux.intel.com >> Link: https://lkml.kernel.org/r/151727417984.33451.1216731042505722161.stgit@dwillia2-desk3.amr.corp.intel.com >> Signed-off-by: David Woodhouse <dwmw@...zon.co.uk> >> [jwang: port to 4.4, no syscall_64] > > This is not complete IMO, the syscall is indeed there, only written in > assembly in 4.4 yet. > > So this patch looks like it is missing these two hunks (from my > SLE12-SP2 backport): > >> --- a/arch/x86/entry/entry_64.S >> +++ b/arch/x86/entry/entry_64.S >> @@ -184,6 +184,8 @@ entry_SYSCALL_64_fastpath: >> cmpl $__NR_syscall_max, %eax >> #endif >> ja 1f /* return -ENOSYS (already in pt_regs->ax) */ >> + sbb %rcx, %rcx /* array_index_mask_nospec() */ >> + and %rcx, %rax >> movq %r10, %rcx >> #ifdef CONFIG_RETPOLINE >> movq sys_call_table(, %rax, 8), %rax >> @@ -282,6 +284,8 @@ tracesys_phase2: >> cmpl $__NR_syscall_max, %eax >> #endif >> ja 1f /* return -ENOSYS (already in pt_regs->ax) */ >> + sbb %rcx, %rcx /* array_index_mask_nospec() */ >> + and %rcx, %rax >> movq %r10, %rcx /* fixup for C */ >> #ifdef CONFIG_RETPOLINE >> movq sys_call_table(, %rax, 8), %rax > > Discovered by Jan Beulich. > > thanks, > -- > js > suse labs Thanks Jiri, yes, indeed, could you send a formal patch of the fix? Thanks! Jack Wang
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.