From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A938C43381 for ; Fri, 22 Feb 2019 00:17:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DED002080F for ; Fri, 22 Feb 2019 00:17:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=vmware.com header.i=@vmware.com header.b="cZjYeicI" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726384AbfBVAR3 (ORCPT ); Thu, 21 Feb 2019 19:17:29 -0500 Received: from mail-eopbgr780052.outbound.protection.outlook.com ([40.107.78.52]:61520 "EHLO NAM03-BY2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726117AbfBVAR3 (ORCPT ); Thu, 21 Feb 2019 19:17:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmware.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xr2PVGnchdEXX3rSpUVBd9tUKC1r1MM2z4aoy96Xjng=; b=cZjYeicILS90TldOk4WQsSNktO7QznvmKQ5//jo0/afUjfblxhgi1ICqa0mLWtP6sO8Jtm0pAYQxC14nT74ubWiVrSnRIiEPHRirq0TfVE5FIi8Qb5neARPV5E2sCIypasY5QXsVxlAZNE+0XD1q6JQ5lx3FmObqg5EegFOiK9c= Received: from BL0PR05MB4772.namprd05.prod.outlook.com (20.177.145.81) by BL0PR05MB4867.namprd05.prod.outlook.com (52.132.15.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.11; Fri, 22 Feb 2019 00:17:25 +0000 Received: from BL0PR05MB4772.namprd05.prod.outlook.com ([fe80::14dc:3a42:ace7:1fbd]) by BL0PR05MB4772.namprd05.prod.outlook.com ([fe80::14dc:3a42:ace7:1fbd%4]) with mapi id 15.20.1665.006; Fri, 22 Feb 2019 00:17:25 +0000 From: Nadav Amit To: Sean Christopherson CC: Rick Edgecombe , Andy Lutomirski , Ingo Molnar , LKML , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Borislav Petkov , Dave Hansen , Peter Zijlstra , Damian Tometzki , linux-integrity , LSM List , Andrew Morton , Kernel Hardening , Linux-MM , Will Deacon , Ard Biesheuvel , Kristen Carlson Accardi , "deneen.t.dock@intel.com" Subject: Re: [PATCH v3 03/20] x86/mm: Save DRs when loading a temporary mm Thread-Topic: [PATCH v3 03/20] x86/mm: Save DRs when loading a temporary mm Thread-Index: AQHUykBLv/ry53ApEkWdFOpKIcxWtaXq8LSAgAACwwA= Date: Fri, 22 Feb 2019 00:17:24 +0000 Message-ID: References: <20190221234451.17632-1-rick.p.edgecombe@intel.com> <20190221234451.17632-4-rick.p.edgecombe@intel.com> <20190222000731.GE7224@linux.intel.com> In-Reply-To: <20190222000731.GE7224@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [208.91.2.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7215046b-f341-4d3f-08d1-08d6985b1f2d x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020);SRVR:BL0PR05MB4867; x-ms-traffictypediagnostic: BL0PR05MB4867: x-microsoft-exchange-diagnostics: 1;BL0PR05MB4867;20:kCefyEeLr/frwa1JE68c7LEkoJ5PAn+3H7G4bxqGfqHBFZJq6o3gubHgcNI+A7zdhuYLucvKVn/NiQ99v7ytY4cE+0KQaNeGX/gMScCg1AQGi4V2H2sFub+5EHQ05F8zV3fWTeQKoIi6PARlGOG4hBW3kaoQDD2R8680F/j27sU= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(136003)(346002)(39860400002)(376002)(396003)(366004)(199004)(189003)(4326008)(305945005)(86362001)(53936002)(7736002)(105586002)(36756003)(2906002)(14454004)(33656002)(6246003)(106356001)(256004)(14444005)(478600001)(102836004)(6346003)(8676002)(81166006)(68736007)(81156014)(8936002)(71200400001)(5660300002)(486006)(26005)(54906003)(186003)(6116002)(25786009)(97736004)(76176011)(476003)(6512007)(53546011)(3846002)(7416002)(71190400001)(66066001)(6916009)(316002)(6506007)(82746002)(229853002)(6436002)(99286004)(446003)(83716004)(6486002)(11346002)(2616005);DIR:OUT;SFP:1101;SCL:1;SRVR:BL0PR05MB4867;H:BL0PR05MB4772.namprd05.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=namit@vmware.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sFnHvFNsYpYPBHlO6+6SeLpWqVuIeNkP4I6BGRlidEoPoRtFdRrn3znVxMjq+M8iCyFHXPh8fofZa31MT1oLrVi5siao2Nu3FI4Ay2vCg90E7/jcGltDsVqXeH1rUPHFxglbnocxvzkAjNjVd4poTGiPsBj/QIXMtsNRojC3kwirR6Hp4ZEnVc1AhJagvrgwspx4lhZYwzm98MnZ4EyP3uJ/YdPOXyqAywpf/N9J2VSgaqlFhDqXpM+T7sY2FtTEXHITJ0nq5VnJ9okG/yqWmvDKm4sDTcvyG/ORgxjJ48k1E2t0TPY/Hiu0HBWY1ZJ5fb1X81Wb1S0IwCZwYPMLBaN9ottmZd4jlgbBipZNKKU6B2APheuF/jxJNq0v1q5RgKGJ67jFh01RbJVuot28ODdkMjTq+ut+gBTlf+9Vmjg= Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7215046b-f341-4d3f-08d1-08d6985b1f2d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 00:17:24.9382 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4867 Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org > On Feb 21, 2019, at 4:07 PM, Sean Christopherson wrote: >=20 > On Thu, Feb 21, 2019 at 03:44:34PM -0800, Rick Edgecombe wrote: >> From: Nadav Amit >>=20 >> Prevent user watchpoints from mistakenly firing while the temporary mm >> is being used. As the addresses that of the temporary mm might overlap >> those of the user-process, this is necessary to prevent wrong signals >> or worse things from happening. >>=20 >> Cc: Andy Lutomirski >> Signed-off-by: Nadav Amit >> --- >> arch/x86/include/asm/mmu_context.h | 25 +++++++++++++++++++++++++ >> 1 file changed, 25 insertions(+) >>=20 >> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/m= mu_context.h >> index d684b954f3c0..0d6c72ece750 100644 >> --- a/arch/x86/include/asm/mmu_context.h >> +++ b/arch/x86/include/asm/mmu_context.h >> @@ -13,6 +13,7 @@ >> #include >> #include >> #include >> +#include >>=20 >> extern atomic64_t last_mm_ctx_id; >>=20 >> @@ -358,6 +359,7 @@ static inline unsigned long __get_current_cr3_fast(v= oid) >>=20 >> typedef struct { >> struct mm_struct *prev; >> + unsigned short bp_enabled : 1; >> } temp_mm_state_t; >>=20 >> /* >> @@ -380,6 +382,22 @@ static inline temp_mm_state_t use_temporary_mm(stru= ct mm_struct *mm) >> lockdep_assert_irqs_disabled(); >> state.prev =3D this_cpu_read(cpu_tlbstate.loaded_mm); >> switch_mm_irqs_off(NULL, mm, current); >> + >> + /* >> + * If breakpoints are enabled, disable them while the temporary mm is >> + * used. Userspace might set up watchpoints on addresses that are used >> + * in the temporary mm, which would lead to wrong signals being sent o= r >> + * crashes. >> + * >> + * Note that breakpoints are not disabled selectively, which also caus= es >> + * kernel breakpoints (e.g., perf's) to be disabled. This might be >> + * undesirable, but still seems reasonable as the code that runs in th= e >> + * temporary mm should be short. >> + */ >> + state.bp_enabled =3D hw_breakpoint_active(); >=20 > Pretty sure caching hw_breakpoint_active() is unnecessary. It queries a > per-cpu value, not hardware's DR7 register, and that same value is > consumed by hw_breakpoint_restore(). No idea if breakpoints can be > disabled while using a temp mm, but even if that can happen, there's no > need to restore breakpoints if they've all been disabled, i.e. if > hw_breakpoint_active() returns false in unuse_temporary_mm(). Good point. I will fix it for next version. Thanks, Nadav