Received: by 10.223.185.116 with SMTP id b49csp7499929wrg; Thu, 1 Mar 2018 06:34:11 -0800 (PST) X-Google-Smtp-Source: AG47ELsiWetHymEs9KRDOxQMLPAR9Q4JrdKf3KS3O1lUDFQzKV9DYGChZ7ifj0vyr4pViX7mSHA7 X-Received: by 10.99.126.17 with SMTP id z17mr1731304pgc.218.1519914851351; Thu, 01 Mar 2018 06:34:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519914851; cv=none; d=google.com; s=arc-20160816; b=jM/1er8sfJZdI7yaHMZyehwFey7dHfHGQltHVUdzSu2A9E4Zyt+WINBbS9d+6PRFJJ rk6Q4tySaV4cNbK7JJXbWg2ladr70DXpaU0eg+e20/0lOMMqiGBf7+RNesC/Vk+Ozcsq cvS6LST6ZmxH+BcezS7Wialaj/Lk7krONrDy8AK0jH+mxrvgqlAcDO4b/+ZfzmsnodRz a3kX6B0KuE7kYwefARkVtvHbJizDHR/Vp5+TMVkgzMhwSNQn8OEBfdkxA9ieRzT7ExC+ JjiWn2CJeSiUzwpuFMNRFkuWL2svoAHt0/tNK7rCdyuBMDMrkD8VbxUhCBotr1n8cyem Vvxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=Ivka0Nki6J2JDDfunAxsnyhXVNFRMYmbOLy6BBuDXDk=; b=bVfmjWmeLMzZAbGFHDiLZmX6C0av20trdOY7w3yqwf+aEvFUyPcNHrYPaA2PQM4cdZ EHUl91Q57lFIzoApG0hKzdVBpmpT4Cnav+1Hom29Tu3R1Gu/KLFMKOVMvvKK9rlEekfK fpUuWaxkWvwEvDl925So2XaavJwB33yaNO7WUlIpLFExyJTR26hykCRcnqtdEcti1f4I rHbjoVhVPVXBE7EiWcZREW9Ut3wEBwK7h9XE3Re6BAeG2Ad+pCpsZ4Zmg8Rw4R6wITLM /RVwesnk6dZorARaooe9w7m/2dndOKfBtLXj3e+7AYUnNENRc40cv6bqLULT8lTLR0hL du6A== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x123si2500523pgb.607.2018.03.01.06.33.56; Thu, 01 Mar 2018 06:34:11 -0800 (PST) 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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031200AbeCAOdR convert rfc822-to-8bit (ORCPT + 99 others); Thu, 1 Mar 2018 09:33:17 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:37056 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1031033AbeCAOdP (ORCPT ); Thu, 1 Mar 2018 09:33:15 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C30A44040852; Thu, 1 Mar 2018 14:33:14 +0000 (UTC) Received: from llong.remote.csb (dhcp-17-5.bos.redhat.com [10.18.17.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0C490946AE; Thu, 1 Mar 2018 14:33:12 +0000 (UTC) Subject: Re: [PATCH 12/31] x86/entry/32: Add PTI cr3 switch to non-NMI entry/exit points To: Joerg Roedel Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Andy Lutomirski , Dave Hansen , Josh Poimboeuf , Juergen Gross , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg KH , Will Deacon , aliguori@amazon.com, daniel.gruss@iaik.tugraz.at, hughd@google.com, keescook@google.com, Andrea Arcangeli , Waiman Long , Pavel Machek , jroedel@suse.de References: <1518168340-9392-1-git-send-email-joro@8bytes.org> <1518168340-9392-13-git-send-email-joro@8bytes.org> <20180301133430.wda4qesqhxnww7d6@8bytes.org> From: Waiman Long Organization: Red Hat Message-ID: <2ae8b01f-844b-b8b1-3198-5db70c3e083b@redhat.com> Date: Thu, 1 Mar 2018 09:33:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20180301133430.wda4qesqhxnww7d6@8bytes.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 01 Mar 2018 14:33:15 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Thu, 01 Mar 2018 14:33:15 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'longman@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/01/2018 08:34 AM, Joerg Roedel wrote: > On Tue, Feb 27, 2018 at 02:18:36PM -0500, Waiman Long wrote: >>> + /* Make sure we are running on kernel cr3 */ >>> + SWITCH_TO_KERNEL_CR3 scratch_reg=%eax >>> + >>> xorl %edx, %edx # error code 0 >>> movl %esp, %eax # pt_regs pointer >>> >> The debug exception calls ret_from_exception on exit. If coming from >> userspace, the C function prepare_exit_to_usermode() will be called. >> With the PTI-32 code, it means that function will be called with the >> entry stack instead of the task stack. This can be problematic as macro >> like current won't work anymore. > Okay, I had another look at the debug handler. As I said before, it > already handles the from-entry-stack case, but with these patches it > gets more likely that we actually hit that path. > > Also, with the special handling for from-kernel-with-entry-stack > situations we can simplify the debug handler and make it more robust > with the diff below. Thoughts? > > diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S > index 8c149f5..844aff1 100644 > --- a/arch/x86/entry/entry_32.S > +++ b/arch/x86/entry/entry_32.S > @@ -1318,33 +1318,14 @@ ENTRY(debug) > ASM_CLAC > pushl $-1 # mark this as an int > > - SAVE_ALL > + SAVE_ALL switch_stacks=1 > ENCODE_FRAME_POINTER > > - /* Make sure we are running on kernel cr3 */ > - SWITCH_TO_KERNEL_CR3 scratch_reg=%eax > - > xorl %edx, %edx # error code 0 > movl %esp, %eax # pt_regs pointer > > - /* Are we currently on the SYSENTER stack? */ > - movl PER_CPU_VAR(cpu_entry_area), %ecx > - addl $CPU_ENTRY_AREA_entry_stack + SIZEOF_entry_stack, %ecx > - subl %eax, %ecx /* ecx = (end of entry_stack) - esp */ > - cmpl $SIZEOF_entry_stack, %ecx > - jb .Ldebug_from_sysenter_stack > - > - TRACE_IRQS_OFF > - call do_debug > - jmp ret_from_exception > - > -.Ldebug_from_sysenter_stack: > - /* We're on the SYSENTER stack. Switch off. */ > - movl %esp, %ebx > - movl PER_CPU_VAR(cpu_current_top_of_stack), %esp > TRACE_IRQS_OFF > call do_debug > - movl %ebx, %esp > jmp ret_from_exception > END(debug) > > > I think that should fix the issue of debug exception from userspace. One thing that I am not certain about is whether debug exception can happen even if the IF flag is cleared. If it can, debug exception should be handled like NMI as the state of the CR3 can be indeterminate if the exception happens in the entry/exit code. Cheers, Longman