Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2378294imu; Thu, 17 Jan 2019 13:07:40 -0800 (PST) X-Google-Smtp-Source: ALg8bN5F8rDxXgEVCy/zygz3YXC+M3Ds7XIj3gAIEnuaBQE1RE1ztWCj9B6Vw8RNxCR/SpaoujZs X-Received: by 2002:a62:6143:: with SMTP id v64mr16509264pfb.142.1547759260412; Thu, 17 Jan 2019 13:07:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547759260; cv=none; d=google.com; s=arc-20160816; b=uw2OGOj1InA1lrlkTRGge5BUMuazn3rUv02cEmifxGQwncF1wnrbCz+iDfCYpxAJ9m vmMKqjSDxlnSB1/G9ISt6IHezaoZ1W1tLa2uxjKOgnSL0/CPxZTp7Hi2IxbhD74sY/jk SxJHWutM3mE3wOIXS6mEvPNM2FOO3aiOr2A7lmuWWeaxMohiUJUtuo1m5OTnt7lG7Pmm +Z0ZRNgE/HR0XUvjnkqq5ZjfzfCFGwY7K1zgeXFap55+VJjd+QBavmGKG4s21a7FeWnj EIeYjdc5rgYmz/ZFuiH41cSbKXhMJ5SnW+EQDjfO+FzvKtV6PQm8stixNkG1wzfYrOap D6RA== 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 :in-reply-to:references:mime-version:dkim-signature; bh=xTOYNcdZ1AfYRoSOgFWyoZ4zslXICLkJkJfxISpksD8=; b=xYe64PYGMUTcpOyy0rPXZVXeILhMZAlSFmwjiQfEBdRNnoepR6Q4pi54t4FEld7Ov+ YGYQCPpVIUHK/efnmDvyZSt2lFqPkdh35X2OIGN5KjFXA9s+LwouknvIkcl3MpdZZ3rr 9PgzRN2eDyO7DWmjEnjojbwdiZduA3iFinIU6Ak18N/2KGlX54i0OVRAnAx62oabPc5z OhwVqDwGcwsp8CpGbKgoaJaL1nhq9kA9WRcHaV17PRO7nkCAN/eh6jSgyeOYFT37TPbg 3zP5WU9JX5VgACLmR75w6f1WCU6gOYijW9lYq2cIj7AagXJ/y1HPZkgruI/M9CvgqK99 acJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="1v/yNJqB"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si2644817pld.331.2019.01.17.13.07.18; Thu, 17 Jan 2019 13:07:40 -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=pass header.i=@kernel.org header.s=default header.b="1v/yNJqB"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727213AbfAQUrw (ORCPT + 99 others); Thu, 17 Jan 2019 15:47:52 -0500 Received: from mail.kernel.org ([198.145.29.99]:59958 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726648AbfAQUrv (ORCPT ); Thu, 17 Jan 2019 15:47:51 -0500 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7414521473 for ; Thu, 17 Jan 2019 20:47:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547758070; bh=n8JMekFCbtwr62FzDCJJoj5l06UUzHpxnzcg5AUI7TM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=1v/yNJqBMgzweIaFgEWtP2lvGXeclrXJB1t0pXSbhZgFbyyQjphalnJPKjN1b7XGp 8qNqL7JXfylXL1R7pc0XXdlb1KZGx/cZBFV5Up9Dgj4W8zDq2uH0g8kHugPIVJxxv3 zqQmR8daNSixtMx2XuYELmKrlF860GrbRVCRB0Yo= Received: by mail-wm1-f47.google.com with SMTP id g67so2493363wmd.2 for ; Thu, 17 Jan 2019 12:47:50 -0800 (PST) X-Gm-Message-State: AJcUukeIJTJHcyKcgBumTDs8pj3jz7aOj8/L51lsuBYDbXr/azlBtbcO e9jex5mif3XY0zUwgYB5K0ElxwwG70JdQ7VzG8uFDw== X-Received: by 2002:a1c:b1d5:: with SMTP id a204mr13844935wmf.32.1547758068833; Thu, 17 Jan 2019 12:47:48 -0800 (PST) MIME-Version: 1.0 References: <20190117003259.23141-1-rick.p.edgecombe@intel.com> <20190117003259.23141-7-rick.p.edgecombe@intel.com> In-Reply-To: From: Andy Lutomirski Date: Thu, 17 Jan 2019 12:47:37 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 06/17] x86/alternative: use temporary mm for text poking To: Andy Lutomirski Cc: Rick Edgecombe , Ingo Molnar , LKML , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Borislav Petkov , Nadav Amit , Dave Hansen , Peter Zijlstra , linux_dti@icloud.com, linux-integrity , LSM List , Andrew Morton , Kernel Hardening , Linux-MM , Will Deacon , Ard Biesheuvel , Kristen Carlson Accardi , "Dock, Deneen T" , Nadav Amit , Kees Cook , Dave Hansen , Masami Hiramatsu 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 Thu, Jan 17, 2019 at 12:27 PM Andy Lutomirski wrote: > > On Wed, Jan 16, 2019 at 4:33 PM Rick Edgecombe > wrote: > > > > From: Nadav Amit > > > > text_poke() can potentially compromise the security as it sets temporary > > PTEs in the fixmap. These PTEs might be used to rewrite the kernel code > > from other cores accidentally or maliciously, if an attacker gains the > > ability to write onto kernel memory. > > i think this may be sufficient, but barely. > > > + pte_clear(poking_mm, poking_addr, ptep); > > + > > + /* > > + * __flush_tlb_one_user() performs a redundant TLB flush when PTI is on, > > + * as it also flushes the corresponding "user" address spaces, which > > + * does not exist. > > + * > > + * Poking, however, is already very inefficient since it does not try to > > + * batch updates, so we ignore this problem for the time being. > > + * > > + * Since the PTEs do not exist in other kernel address-spaces, we do > > + * not use __flush_tlb_one_kernel(), which when PTI is on would cause > > + * more unwarranted TLB flushes. > > + * > > + * There is a slight anomaly here: the PTE is a supervisor-only and > > + * (potentially) global and we use __flush_tlb_one_user() but this > > + * should be fine. > > + */ > > + __flush_tlb_one_user(poking_addr); > > + if (cross_page_boundary) { > > + pte_clear(poking_mm, poking_addr + PAGE_SIZE, ptep + 1); > > + __flush_tlb_one_user(poking_addr + PAGE_SIZE); > > + } > > In principle, another CPU could still have the old translation. Your > mutex probably makes this impossible, but it makes me nervous. > Ideally you'd use flush_tlb_mm_range(), but I guess you can't do that > with IRQs off. Hmm. I think you should add an inc_mm_tlb_gen() here. > Arguably, if you did that, you could omit the flushes, but maybe > that's silly. > > If we start getting new users of use_temporary_mm(), we should give > some serious thought to the SMP semantics. > > Also, you're using PAGE_KERNEL. Please tell me that the global bit > isn't set in there. > Much better solution: do unuse_temporary_mm() and *then* flush_tlb_mm_range(). This is entirely non-sketchy and should be just about optimal, too. --Andy