From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757509AbcAOK4L (ORCPT ); Fri, 15 Jan 2016 05:56:11 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:33457 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754135AbcAOK4I (ORCPT ); Fri, 15 Jan 2016 05:56:08 -0500 Date: Fri, 15 Jan 2016 11:56:04 +0100 From: Ingo Molnar To: Josh Poimboeuf Cc: Borislav Petkov , 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: <20160115105603.GA25002@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20160115060652.GA16760@treble.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Josh Poimboeuf wrote: > Some of the 'weird' cases: > > - Some functions use 'ljmp' or 'lret'. After looking at this some more, > I think it would be safe for stacktool to translate the use of these > instructions to mean "I know what I'm doing" and just ignore the > function. 100% of the functions are safe to ignore anyway. So we can > get rid of those markers and just make stacktool smarter. Yeah. So the worry people have is that once such annotations get in, the incentive to solve them at the tooling level decreases and stays on a TODO list for a long time ;-) > - 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) Yeah, probably. Annotating Xen special code looks acceptable. > - 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). I think annotation is fine in this case. > - __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. That is obviously a special case too. As long as no 'usual' C function gets annotated as doing something weird with the stack frame, I'm fine with this approach. Thanks, Ingo