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=-8.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, T_DKIMWL_WL_MED,USER_IN_DEF_DKIM_WL 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 E1A3AC433F4 for ; Sun, 26 Aug 2018 22:48:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 828402174A for ; Sun, 26 Aug 2018 22:48:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="sa1WeKIe" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 828402174A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727056AbeH0Ccj (ORCPT ); Sun, 26 Aug 2018 22:32:39 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:33749 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726886AbeH0Ccj (ORCPT ); Sun, 26 Aug 2018 22:32:39 -0400 Received: by mail-oi0-f66.google.com with SMTP id 8-v6so24213350oip.0 for ; Sun, 26 Aug 2018 15:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9kja6EKcXqqjnmzW2H8iq+TMhfbXGWXL1OC3ffYvWeA=; b=sa1WeKIe2aO8sU7QNyKFlhTa2Ql9YfNe46gksYsH9hoLqrBHq7zAtSOJmunLJb0G0p e4dZI11eT4QBKKSNtr/ZSM+dnkm9Tdgjyjz8GhhJesc1ygsdN8wER94x+4pakbOSQa3j RfHUpX/NbL8+uPQZafdYxXLG4W8AyX11wlOzbOTBE4jtXJ27Uge7nOY/pevusIaUag0P xJFBp7DnYOAxfmF05uyx0gc2YubwF36dGM2JD954MjTpJhMUJKSF812uS9wgfR9M6Mwc jtBEWlxXc+KSJA6zKN4W6zhrEi0kjyjHmCbOpauh7k8fQIQ+c0BRPuQHoUmzGIl+1i0A LeaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9kja6EKcXqqjnmzW2H8iq+TMhfbXGWXL1OC3ffYvWeA=; b=SGbkXuelMWNd1X42mu0x50e7qET+L6LpLqWMh5LIMDtuR6PZLZxBJQU80+fNNcGalC IlCgbqaMegyVmzkXWZ0Ha4QbWLd/2rnxkp70S+KQD0HIx5ON9Aw2QGYJct1/3qttz80Q aDfVtp8MOacMUCjUgXofMdrYsNntRojCH08EOgeavVQJIv4RCHNjx6l13FPyCuexwuYU q6u6AHEP22c4Jp/2O85rhLzf9VZ+YGKxi0+AQqHsOSRDTiB8V1zoPUunJpSvw8jcZhr3 7Wac21d4+VLuuj97232VeqdoCtktn67kZTLMTqrPtyvr9ISfBTpW+fGgBZWf9V+Bz2fQ n50g== X-Gm-Message-State: APzg51BKDOg33syBk3LFr/6cUc1lZ3u+futnOdpCjNwd8Rmb80uCkgcJ 7LSsTsuy12GrPZH4UoxFCHp98uOJt01TubCzoV5r2A== X-Google-Smtp-Source: ANB0VdaQYT60G7xfC+9v4Bxje6yBjtkNU+h2hLPLJa+mtQF1OYo4UDeF0eezxruP0dT9ajict9Bp0yqWv0cjq4GmI9A= X-Received: by 2002:aca:4204:: with SMTP id p4-v6mr9503346oia.242.1535323720160; Sun, 26 Aug 2018 15:48:40 -0700 (PDT) MIME-Version: 1.0 References: <20180822153012.173508681@infradead.org> <20180822154046.823850812@infradead.org> <20180822155527.GF24124@hirez.programming.kicks-ass.net> <20180823134525.5f12b0d3@roar.ozlabs.ibm.com> <776104d4c8e4fc680004d69e3a4c2594b638b6d1.camel@au1.ibm.com> <20180823133958.GA1496@brain-police> <20180824084717.GK24124@hirez.programming.kicks-ass.net> <20180824180438.GS24124@hirez.programming.kicks-ass.net> <56A9902F-44BE-4520-A17C-26650FCC3A11@gmail.com> <9A38D3F4-2F75-401D-8B4D-83A844C9061B@gmail.com> <8E0D8C66-6F21-4890-8984-B6B3082D4CC5@gmail.com> <20180826112341.f77a528763e297cbc36058fa@kernel.org> In-Reply-To: From: Jann Horn Date: Mon, 27 Aug 2018 00:48:13 +0200 Message-ID: Subject: Re: TLB flushes on fixmap changes To: Andy Lutomirski , Kees Cook Cc: mhiramat@kernel.org, Nadav Amit , Linus Torvalds , Paolo Bonzini , jkosina@suse.cz, Peter Zijlstra , Will Deacon , benh@au1.ibm.com, npiggin@gmail.com, "the arch/x86 maintainers" , Borislav Petkov , Rik van Riel , Adin Scannell , Dave Hansen , kernel list , Linux-MM , "David S. Miller" , Martin Schwidefsky , Michael Ellerman 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 Sun, Aug 26, 2018 at 6:21 AM Andy Lutomirski wrote: > > On Sat, Aug 25, 2018 at 7:23 PM, Masami Hiramatsu wrote: > > On Fri, 24 Aug 2018 21:23:26 -0700 > > Andy Lutomirski wrote: > >> Couldn't text_poke() use kmap_atomic()? Or, even better, just change CR3? > > > > No, since kmap_atomic() is only for x86_32 and highmem support kernel. > > In x86-64, it seems that returns just a page address. That is not > > good for text_poke, since it needs to make a writable alias for RO > > code page. Hmm, maybe, can we mimic copy_oldmem_page(), it uses ioremap_cache? > > > > I just re-read text_poke(). It's, um, horrible. Not only is the > implementation overcomplicated and probably buggy, but it's SLOOOOOW. > It's totally the wrong API -- poking one instruction at a time > basically can't be efficient on x86. The API should either poke lots > of instructions at once or should be text_poke_begin(); ...; > text_poke_end();. > > Anyway, the attached patch seems to boot. Linus, Kees, etc: is this > too scary of an approach? With the patch applied, text_poke() is a > fantastic exploit target. On the other hand, even without the patch > applied, text_poke() is every bit as juicy. Twiddling CR0.WP is incompatible with Xen PV, right? It can't let you do it because you're not actually running in ring 0 (but in ring 1 or 3), so CR0.WP has no influence on what you can access; and it must not let you bypass write protection because you have read-only access to host page tables. I think this code has to be compatible with Xen PV, right? In theory Xen PV could support this by emulating X86 instructions, but I don't see anything related to CR0.WP in their emulation code. From xen/arch/x86/pv/emul-priv-op.c: case 0: /* Write CR0 */ if ( (val ^ read_cr0()) & ~X86_CR0_TS ) { gdprintk(XENLOG_WARNING, "Attempt to change unmodifiable CR0 flags\n"); break; } do_fpu_taskswitch(!!(val & X86_CR0_TS)); return X86EMUL_OKAY; Having a special fallback path for "patch kernel code while running under Xen PV" would be kinda ugly.