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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 31 Aug 2018 09:20:18 -0700 From: Yu-cheng Yu <yu-cheng.yu@...el.com> To: Jann Horn <jannh@...gle.com> Cc: the arch/x86 maintainers <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, kernel list <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org, Linux-MM <linux-mm@...ck.org>, linux-arch <linux-arch@...r.kernel.org>, Linux API <linux-api@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>, Andy Lutomirski <luto@...capital.net>, Balbir Singh <bsingharora@...il.com>, Cyrill Gorcunov <gorcunov@...il.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Florian Weimer <fweimer@...hat.com>, hjl.tools@...il.com, Jonathan Corbet <corbet@....net>, keescook@...omium.org, Mike Kravetz <mike.kravetz@...cle.com>, Nadav Amit <nadav.amit@...il.com>, Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>, Peter Zijlstra <peterz@...radead.org>, ravi.v.shankar@...el.com, vedvyas.shanbhogue@...el.com Subject: Re: [RFC PATCH v3 06/24] x86/cet: Control protection exception handler On Fri, 2018-08-31 at 17:01 +0200, Jann Horn wrote: > Is there a reason why all the code in this patch isn't #ifdef'ed > away > on builds that don't support CET? It looks like the CET handler is > hooked up to the IDT conditionally, but the handler code is always > built? Yes, in idt.c, it should have been: #ifdef CONFIG_X86_64 INTG(X86_TRAP_CP, control_protection), #endif I will fix it. > > +dotraplinkage void > > +do_control_protection(struct pt_regs *regs, long error_code) > > +{ > > + struct task_struct *tsk; > > + > > + RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't > > wake RCU"); > > + if (notify_die(DIE_TRAP, "control protection fault", regs, > > + error_code, X86_TRAP_CP, SIGSEGV) == > > NOTIFY_STOP) > > + return; > > + cond_local_irq_enable(regs); > > + > > + if (!user_mode(regs)) > > + die("kernel control protection fault", regs, > > error_code); > > + > > + if (!static_cpu_has(X86_FEATURE_SHSTK) && > > + !static_cpu_has(X86_FEATURE_IBT)) > > + WARN_ONCE(1, "CET is disabled but got control " > > + "protection fault\n"); > > + > > + tsk = current; > > + tsk->thread.error_code = error_code; > > + tsk->thread.trap_nr = X86_TRAP_CP; > > + > > + if (show_unhandled_signals && unhandled_signal(tsk, > > SIGSEGV) && > > + printk_ratelimit()) { > > + unsigned int max_err; > > + > > + max_err = ARRAY_SIZE(control_protection_err) - 1; > > + if ((error_code < 0) || (error_code > max_err)) > > + error_code = 0; > > + pr_info("%s[%d] control protection ip:%lx sp:%lx > > error:%lx(%s)", > > + tsk->comm, task_pid_nr(tsk), > > + regs->ip, regs->sp, error_code, > > + control_protection_err[error_code]); > > + print_vma_addr(" in ", regs->ip); > Shouldn't this be using KERN_CONT, like other callers of > print_vma_addr(), to get the desired output? I will change it.
Powered by blists - more mailing lists