Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp4323168imm; Sat, 21 Jul 2018 16:21:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfj1D7EetSODw/9laNoN6YSxf/rlMKqw2mD4Tk7QP5fJnA7GzpklSiIYVhAuXOM8+tuIWMf X-Received: by 2002:a17:902:243:: with SMTP id 61-v6mr7152572plc.301.1532215276386; Sat, 21 Jul 2018 16:21:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532215276; cv=none; d=google.com; s=arc-20160816; b=URMitZyXEXHEJGMG5yljp9O0FW8py/Tdfzx04KfcQ7+zYZo+vrKaenz/Ae1shSNDEd kpjvQiM8go5teEPy7iPzvMyHu7jTG23A0UQDJbPc+yTywWu2DKBaLfIRqhOwPKpjEmXI mTQN8T2g2fPBpF20k/O37Hv/3JVHNtoUprh8xWPfO0+lQ8Gb2D2ycGH85uI1o94VAMSF w/dmYrGY0YiVkHLJwlgW+GKtHprWbxqMsP84e1bq+jZbqX11IPyx5Zq9tFlW+XC0vUIl /kkmdfYrsXUHZxN0m6yhxwimQBVL87hSosrmVAFR2La2No0YIMlwuzcW6lEpYWCa0pod DXAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=er6te3rzUbnDT8LNfuu2lR4oud7fJCbesH3cinpT2ak=; b=QeRX7DSJw5oZV1dWG70VcPcbR3z9MzRCI1F2jfivQ0nmjFECovRTg134K42Gjg+YC5 Eox/S9sZfHTE4wCjrsVQj9Kh+Ym+aXB/PqvxJOYh/UCpHR7DL8lqzNU0fNPrl5RptZTY rMUZhg1wFoj+Yylgqf+UDvXrUccdiFHWAPQOLG2aCE3m/GhHEHQ6Id+2PhMSBnsGP3W3 5t1UelZbU/nN4vedJR2mcu3FAWD6mjsQ4nl5MFjzAib45by8Z/u7K7EfeN5dkLf+sYPx WuJrl0DMdEHChmEmsJNc5NG21VOvBNTyTh1l+vTd4gk9qRcGEWGfOWU1/VQJvwt24KCk VROg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@runbox.com header.s=rbselector1 header.b=KvGixHUH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cd4-v6si5056984plb.516.2018.07.21.16.21.02; Sat, 21 Jul 2018 16:21:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@runbox.com header.s=rbselector1 header.b=KvGixHUH; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728704AbeGVANq (ORCPT + 99 others); Sat, 21 Jul 2018 20:13:46 -0400 Received: from aibo.runbox.com ([91.220.196.211]:36434 "EHLO aibo.runbox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728253AbeGVANq (ORCPT ); Sat, 21 Jul 2018 20:13:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=er6te3rzUbnDT8LNfuu2lR4oud7fJCbesH3cinpT2ak=; b=KvGixHUHNdstKTDqUth0eucxnn MTAYP1U6dYpRPE7b3sny2Zbn5aXmFttLLx0J85SlyCKbu99HXRqF6+EMsxTjK9a1ZC23eDNDsWPYQ QSNTZ50+GRVQjF1+T5l9Hfothoxa7R01iSZBBaNLuAfabXwPdNnnQAd+GJ7gHjohwUAJHi2oMaNYX aka+YNoBusIaubO2xZB265DV+oJ6oj6TBcTwKhzhegcBj6+WB1zyozzS7vDAA94Fw99gw3PjwmBrh f3NwOpknCOgrkvZH7eRvIg0ecPdq1GJBx5d0+U7z154gZ7D78Dt5K2Sr16DRuM6vVrUXFSQ/EDcP0 afm+HgMA==; Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fh19Y-0006lG-7o; Sun, 22 Jul 2018 01:19:08 +0200 Received: by mailfront12.runbox.com with esmtpsa (uid:769847 ) (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) id 1fh19V-0008BO-Sx; Sun, 22 Jul 2018 01:19:06 +0200 Subject: Re: [PATCH 1/2] x86/entry/64: Do not clear %rbx under Xen To: Andy Lutomirski Cc: LKML , Dominik Brodowski , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Boris Ostrovsky , Juergen Gross , xen-devel@lists.xenproject.org, X86 ML , stable , Dan Williams , Andi Kleen References: <20180721194909.23903-1-m.v.b@runbox.com> From: "M. Vefa Bicakci" Message-ID: Date: Sat, 21 Jul 2018 19:19:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/21/2018 05:45 PM, Andy Lutomirski wrote: > On Sat, Jul 21, 2018 at 12:49 PM, M. Vefa Bicakci wrote: >> Commit 3ac6d8c787b8 ("x86/entry/64: Clear registers for >> exceptions/interrupts, to reduce speculation attack surface") unintendedly >> broke Xen PV virtual machines by clearing the %rbx register at the end of >> xen_failsafe_callback before the latter jumps to error_exit. >> error_exit expects the %rbx register to be a flag indicating whether >> there should be a return to kernel mode. >> >> This commit makes sure that the %rbx register is not cleared by >> the PUSH_AND_CLEAR_REGS macro, when the macro in question is instantiated >> by xen_failsafe_callback, to avoid the issue. > > Seems like a genuine problem, but: > >> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S >> index c7449f377a77..96e8ff34129e 100644 >> --- a/arch/x86/entry/entry_64.S >> +++ b/arch/x86/entry/entry_64.S >> @@ -1129,7 +1129,7 @@ ENTRY(xen_failsafe_callback) >> addq $0x30, %rsp >> UNWIND_HINT_IRET_REGS >> pushq $-1 /* orig_ax = -1 => not a system call */ >> - PUSH_AND_CLEAR_REGS >> + PUSH_AND_CLEAR_REGS clear_rbx=0 >> ENCODE_FRAME_POINTER >> jmp error_exit > > The old code first set RBX to zero then, if frame pointers are on, > sets it to some special non-zero value, then crosses its fingers and > hopes for the best. Your patched code just skips the zeroing part, so > RBX either contains the ENCODE_FRAME_POINTER result or is > uninitialized. > > How about actually initializing rbx to something sensible like, say, 1? Hello Andy, Thank you for the review! Apparently, I have not done my homework fully. I will test your suggestion and report back, most likely in a few hours. I have been testing with the next/linux-next tree's master branch (dated 20180720), and I noticed that ENCODE_FRAME_POINTER changes the frame pointer (i.e., RBP) register, as opposed to the RBX register, which the patch aims to avoid changing before jumping to error_exit. It is possible that I am missing something though -- I am not sure about the connection between the RBP and RBX registers. The change introduced by commit 3ac6d8c787b8 is in the excerpt below. Would it be valid to state that the original code had the same issue that you referred to (i.e., leaving the RBX register uninitialized)? [I also realized that I forgot to include Andi Kleen and Dan Williams, authors of 3ac6d8c787b8, in the discussion; I am copying this e-mail to them as well.] Thank you, Vefa $ git show -W 3ac6d8c787b8 -- arch/x86/entry/entry_64.S ... ENTRY(xen_failsafe_callback) UNWIND_HINT_EMPTY movl %ds, %ecx cmpw %cx, 0x10(%rsp) jne 1f movl %es, %ecx cmpw %cx, 0x18(%rsp) jne 1f movl %fs, %ecx cmpw %cx, 0x20(%rsp) jne 1f movl %gs, %ecx cmpw %cx, 0x28(%rsp) jne 1f /* All segments match their saved values => Category 2 (Bad IRET). */ movq (%rsp), %rcx movq 8(%rsp), %r11 addq $0x30, %rsp pushq $0 /* RIP */ UNWIND_HINT_IRET_REGS offset=8 jmp general_protection 1: /* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */ movq (%rsp), %rcx movq 8(%rsp), %r11 addq $0x30, %rsp UNWIND_HINT_IRET_REGS pushq $-1 /* orig_ax = -1 => not a system call */ ALLOC_PT_GPREGS_ON_STACK SAVE_C_REGS SAVE_EXTRA_REGS + CLEAR_REGS_NOSPEC ENCODE_FRAME_POINTER jmp error_exit END(xen_failsafe_callback) ...