From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753619AbbDBMcK (ORCPT ); Thu, 2 Apr 2015 08:32:10 -0400 Received: from mail-wg0-f44.google.com ([74.125.82.44]:34709 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753455AbbDBMcE (ORCPT ); Thu, 2 Apr 2015 08:32:04 -0400 Date: Thu, 2 Apr 2015 14:31:59 +0200 From: Ingo Molnar To: Denys Vlasenko Cc: Brian Gerst , Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , Borislav Petkov , Linus Torvalds , Borislav Petkov Subject: Re: [PATCH urgent v2] x86, asm: Disable opportunistic SYSRET if regs->flags has TF set Message-ID: <20150402123159.GA25151@gmail.com> References: <9472f1ca4c19a38ecda45bba9c91b7168135fcfa.1427923514.git.luto@kernel.org> <20150402090744.GA26846@gmail.com> <551D14D3.1070907@redhat.com> <20150402103735.GA21105@gmail.com> <551D3503.6000508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551D3503.6000508@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 * Denys Vlasenko wrote: > On 04/02/2015 01:14 PM, Brian Gerst wrote: > >>>> So I merged this as it's an obvious bugfix, but in hindsight I'm > >>>> really uneasy about the whole opportunistic SYSRET concept: it appears > >>>> that the chance that %rcx matches return-%rip is astronomical - this > >>>> is why this bug wasn't noticed live so far. > >>>> > >>>> So should we really be doing this? > >>> > >>> Andy does this not for the off-chance that userspace's RCX is equal > >>> to return address and R11 == RFLAGS. The chances of that are > >>> astronomically small. > >>> > >>> This code path triggers when ptrace/audit/seccomp is active. Instead > >>> of torturing ourselves trying to not divert into IRET return, now > >>> code is steered that way. But then immediately before actual IRET, > >>> we check again: "do we really need IRET?" IOW "did ptrace really > >>> touch pt_regs->ss? ->flags? ->rip? ->rcx?" which in vast majority of > >>> cases will not be true. > >> > >> I keep forgetting about that, my test systems have the audit muck > >> turned off ;-) > >> > >> Fair enough - and it's sensible to share the IRET path between > >> interrupts and complex-return system calls, even though the check > >> is unnecessary overhead for the pure interrupt return path... > > > > > > Maybe we could reintroduce TIF_IRET for this purpose instead of > > (ab)using TIF_NOTIFY_RESUME. Then we would only do the opportunistic > > check for those cases (ptrace, audit, exec, sigreturn, etc.), and skip > > it for interrupts. > > The very first check in the existing code, pt_regs->cx == > pt_regs->ip, will fail for interrupt returns. > > You hardly can save anything by placing a (ti->flags & > TIF_TRY_SYSRET) check in front of it, it's almost as expensive. Well, what I was thinking of was to have a pure irq (well, async context) return path, not shared with the weird-syscall-IRET return path at all ... It would be open coded, not obfuscated via macros. That way AFAICS the upsides are: - it's easier to read (and maintain) what goes on in which case. '*intr*' labels would truly identify interrupt return related processing, for a change! - we can optimize in a more directed fashion - like here ... while the downsides are: - more code - a (small) chance of a fix going to one path while not the other. How much extra code would it be? Thanks, Ingo