Received: by 10.223.185.116 with SMTP id b49csp2900775wrg; Mon, 5 Mar 2018 10:25:38 -0800 (PST) X-Google-Smtp-Source: AG47ELszlKIhmH3mmZu11qN1u/nKqI97JcF1e2GTtVQV001I+NWCU/gLdGzdTJKyX8ChY1FVYGBi X-Received: by 2002:a17:902:2f81:: with SMTP id t1-v6mr14088793plb.290.1520274338827; Mon, 05 Mar 2018 10:25:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520274338; cv=none; d=google.com; s=arc-20160816; b=PGrregbzDSaawELZ9TEBwpFRacb8gnTCbpTtnKM6cislzJY8/xVTLlGOqGTr1Kw1Dc wCVE6F0e/Ew9Z6qi2rjMXP0jbSatCfCjFzei4+C97BbTfMmTBhvyNwnH0znRMcnWzfyN wO+D9ij7rsnEEa5YQatoE5jgJAtl0FpvvaH1rIfGmMhBbjAqNBcJBCa2yBJ/sy85yyPw 2WVAMBgRGg7OS5vyt/7pzG/7zicRmbWH1RUVDHO62Gvlb11ishzNMMxNb0w4LgoJXqqY jycFPP4kXrjw/SKcaeb5E7DIOzV2lhxfquW/xRMi80noZqG71yjeh2HNanWGjqVJoth5 rgqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=1QA5HB/Ws/FGBbTznxvPXKMN1Jkg/65sWe+aV0LJlT0=; b=AWiJbz+ZuEr2bpLLT7jadnKg3zmCHe/uJmlzAXvGQJZknuixgW40M/05EwSLgBwfK+ ggh7bz14XRLRIiq+zKPawkiMvIVTtqmUh50t4qsS9TiOFZC4KJRymJUuDLLOt/nWA43Q DH6KVxVXjfZiBp1SdQhkZZWS1OAwwOZUscl4e8ggiTo+4Od/KDd3ErOxg0abmiW5nYRz 6RwGOyETqMcVp38Ko+Gmp+mGY47nRe5pLAtWlq7MosQPLp8bU85r8S5Ms6UhrBKY8aJR B0OOZWZl0N+TXZqSBaaadp5SWWdd4CJ5Rv4ZZkBXNW5zMRl3HqafwDAGjImsyW3A6LJf mOFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=O2nhZ4t4; dkim=fail header.i=@linux-foundation.org header.s=google header.b=LuvWwWsD; 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 k3si10545619pfj.24.2018.03.05.10.25.24; Mon, 05 Mar 2018 10:25:38 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=O2nhZ4t4; dkim=fail header.i=@linux-foundation.org header.s=google header.b=LuvWwWsD; 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 S932266AbeCESYC (ORCPT + 99 others); Mon, 5 Mar 2018 13:24:02 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:38085 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838AbeCESYA (ORCPT ); Mon, 5 Mar 2018 13:24:00 -0500 Received: by mail-it0-f67.google.com with SMTP id j7so11296556ita.3 for ; Mon, 05 Mar 2018 10:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1QA5HB/Ws/FGBbTznxvPXKMN1Jkg/65sWe+aV0LJlT0=; b=O2nhZ4t4ce9YZ55YhM1RNe5gU6byv8AVn/zOoKUJDOL9bGm4koDFwnQ+Fp9KKOpMeL fxx0HBbyva8hVN9zYqH9O7HAbT87oBoHEQKBCVjVjsuChNb4OFAwC/kdkEQJobasVF0z ahL5h+cUW8/qNu3dZQG4ZrXyI+jxdPCicd5VLMADpLDkYX0/wKjWiWJFlXOJm6MjbP7F K3TtLHuMuHHyqtthw8Awb7OXQtM3wn54zyVlvGqqg2P9TyPeUYr/6DMMEEoPg95mTXjM DUjwxoYlOnGHrhdziSA8tGs+34B8vVkYTCdzw+EoqLPv+LrX7RYsIB/6pZnEboiU/8DB YOsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1QA5HB/Ws/FGBbTznxvPXKMN1Jkg/65sWe+aV0LJlT0=; b=LuvWwWsDOJxnTWMYX5ePTsW5MBGwhd5maBnoMGifz89hsP5pZ2h9X1gPG8RM4JGAUb ZDxhOgyO2UAuVCUQMz7lXKNnkIwTieuGLSqg5DnagLieDTpScaZ2kaUeVeStIsGpDlVX 9FcsJkzFB5kvK0Rfm2Sod++Dd35zpSe1TeroY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1QA5HB/Ws/FGBbTznxvPXKMN1Jkg/65sWe+aV0LJlT0=; b=SJnDOp78J1uKcHAJ/UCy4h0lwpvNTlvcRfAD8VtlesJFFv2plAvfKZq10K+I4gCL7A ciKazLdoqy60ceupkGb4O5wwY5KuNtDciyv1X/NsuhitQFlJkp2Fqaqxcry5X7RHU7cB nzDqpuYHEEm+lH3PXKVxJPOeMb/phUQJlMzV/6VDrOXCA8m34i+B+r98Ai+7OVtF52Eq qLJV/tmV+fVNgvBS/eH13/44WOep5aawxxUi1LxCd9T3VEJnMy2ZlqzQfpA3D5Fbay+W 5Tg9MK5rO2fAAzR1vGYdnchZmEBtjKS0YqUgTm0JXTfUwdD/Bmb+PLoBWsSNOeQG7mWn vdTQ== X-Gm-Message-State: AElRT7FsT1M7RhahJI0zTsV3nWbOTOiNQ2qk19abxtHa+1vlGdCKeyMT XuD1UG+sP/c2jarHWkdDKNLGqO6SB4O8WfhjSaQ= X-Received: by 10.36.69.196 with SMTP id c65mr14989175itd.16.1520274239816; Mon, 05 Mar 2018 10:23:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Mon, 5 Mar 2018 10:23:59 -0800 (PST) In-Reply-To: <20180305131231.GR16484@8bytes.org> References: <1520245563-8444-1-git-send-email-joro@8bytes.org> <1520245563-8444-8-git-send-email-joro@8bytes.org> <20180305131231.GR16484@8bytes.org> From: Linus Torvalds Date: Mon, 5 Mar 2018 10:23:59 -0800 X-Google-Sender-Auth: c8dcRYPvap0uRrBrOYcGIc1ZUB4 Message-ID: Subject: Re: [PATCH 07/34] x86/entry/32: Restore segments before int registers To: Joerg Roedel Cc: Thomas Gleixner , Ingo Molnar , Peter Anvin , "the arch/x86 maintainers" , Linux Kernel Mailing List , linux-mm , Andrew Lutomirski , Dave Hansen , Josh Poimboeuf , =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Peter Zijlstra , Borislav Petkov , Jiri Kosina , Boris Ostrovsky , Brian Gerst , David Laight , Denys Vlasenko , Eduardo Valentin , Greg Kroah-Hartman , Will Deacon , "Liguori, Anthony" , Daniel Gruss , Hugh Dickins , Kees Cook , Andrea Arcangeli , Waiman Long , Pavel Machek , Joerg Roedel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 5, 2018 at 5:12 AM, Joerg Roedel wrote: > >> The things is, we *know* that we will restore two segment registers with the >> user cr3 already loaded: CS and SS get restored with the final iret. > > Yeah, I know, but the iret-exception path is fine because it will > deliver a SIGILL and doesn't return to the faulting iret. That's not so much my worry, as just getting %cr3 wrong. The fact is, we still take the exception, and we still have to handle it, and that still needs to get the user<->kernel cr3 right. So then the whole "restore segments early" must be wrong, because *that* path must get it all right too, no? And it appears that the code *does* get it right, and you can just avoid this patch entirely? > The iret-exception case is tested by the ldt_gdt selftest (the > do_multicpu_tests subtest). But I didn't actually tested single-stepping > through sysenter yet. I just re-ran the same tests I did with v2 on this > patch-set. Ok. Maybe we should have a test for the "take DB on first instruction of sysenter". Linus