From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757310AbcAOKmL (ORCPT ); Fri, 15 Jan 2016 05:42:11 -0500 Received: from mail.skyhub.de ([78.46.96.112]:34885 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755175AbcAOKmD (ORCPT ); Fri, 15 Jan 2016 05:42:03 -0500 Date: Fri, 15 Jan 2016 11:41:45 +0100 From: Borislav Petkov To: Josh Poimboeuf Cc: Ingo Molnar , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, Michal Marek , Peter Zijlstra , Andy Lutomirski , Linus Torvalds , Andi Kleen , Pedro Alves , Namhyung Kim , Bernd Petrovitsch , Chris J Arges , Andrew Morton , Jiri Slaby , Arnaldo Carvalho de Melo Subject: Re: [PATCH v15 13/25] x86/reboot: Add ljmp instructions to stacktool whitelist Message-ID: <20160115104145.GC25104@pd.tnic> References: <20160112164711.GD22699@pd.tnic> <20160112174301.GD310@treble.redhat.com> <20160113105503.GB11575@gmail.com> <20160115060652.GA16760@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160115060652.GA16760@treble.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2016 at 12:06:52AM -0600, Josh Poimboeuf wrote: > - xen_cpuid() uses some custom xen instructions which start with > XEN_EMULATE_PREFIX. It corresponds to the following x86 instructions: > > ffffffff8107e572: 0f 0b ud2 > ffffffff8107e574: 78 65 js ffffffff8107e5db > ffffffff8107e576: 6e outsb %ds:(%rsi),(%dx) > > Apparently(?) xen treats the ud2 special when it's followed by "78 65 > 6e". This is confusing for stacktool because ud2 is normally a dead > end, and it thinks the instructions after it will never run. > > (In theory stacktool could be taught to understand this hack, but > that's a bad idea IMO) Why, because it is not generic enough? Well, you could add a cmdline option "--kernel" which is supplied when checking the kernel and such kernel "idiosyncrasies" are handled only then and there. And since the tool is part of the kernel, changes to XEN_EMULATE_PREFIX, will have to be updated in stacktool too... > - The error path in arch/x86/net/bpf_jit.S uses 'leaveq' to do a double > return so that it returns from its caller's context. stacktool > doesn't know how to distinguish this from a frame pointer programming > bug. I think the only way to avoid a whitelist marker here would be > to rewrite the bpf code to conform with more traditional rbp usage > (but I don't know if that would really be a good idea because it would > probably result in slower/more code). Could also be part of the "--kernel"-specific checking and you could match the containing ELF symbol bpf_error... > - __bpf_prog_run() uses a jump table: > > goto *jumptable[insn->code]; > > stacktool doesn't have an x86 emulator, so it doesn't know how to > deterministically follow all possible branches for a dynamic jump. > > - schedule() mucks with the frame pointer which is normally not allowed. I think if we put all those checks that under --kernel, the tool would remain generic enough. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.