Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5287087imm; Sun, 26 Aug 2018 15:50:29 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYIu0LMbQDqcDdq0KqKusG++41lfCwJNg9MNfJqMdnzNkegp2I+pQZJDFejvLipsBSL9I4z X-Received: by 2002:a63:fa49:: with SMTP id g9-v6mr9970975pgk.18.1535323829511; Sun, 26 Aug 2018 15:50:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535323829; cv=none; d=google.com; s=arc-20160816; b=cC66rwt7KCidfD+WwzLgGjhSNFS4FY7qcRjKUgPJL8VlSStrl4iEYPS7KBT3MBbb1l 3zZebxTqxL+3UKg1/JzUwfiwlrXLMzL4mMLlGq+GO0Ao9zI6oSfbTJRCUMq1mJZgpGFm wHYm5rZzGr7lSmWEIySYwceYT3kf57EhFh3HxyoUdcMjuf2bQnuBIa/aTwBpHEVhteF1 8gliiO7id7UKdbCiDbgyLwQRLM9P9N5zFIf9WQPJ1+wlK/52hid8receoA4tOoKUH6gc qgZVcO4EuX3Pmno52YwMiDIHDpLhg8DEKbJeOGla60LSgS/PrLqHkvZuxiAZHf3PrAKK nj4Q== 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 :arc-authentication-results; bh=9kja6EKcXqqjnmzW2H8iq+TMhfbXGWXL1OC3ffYvWeA=; b=b7+UrHZI1K8cesVEx2qQ3HsPBEYaQlj9fVfS+lzR0bfI1p8OU67Wxe3znoTDt4iXbo ePyZ1tvci8J+34arIUWXjlPX+K8zbUU3ADUWWqp7odQs2/U3fvIbh4IIhXWCb/iGL144 +CPwbTVBDYOjjX5h6sAukRq982otQJurXx1S9Dk7W3RNdEPf01WnZZ/TQ0+VAfK4hoP6 bM1jVAUqWNSTyQw/S11bNJY5sVU/V93q5vy1aVW6NHwIrLSll0hiZIzzZaMwkOyc8n7z N0suDKVJgNjg7vqZo6qs3r7GfdDLXfjAMpGxHTWhyzYG7n9XBq5h41Dlb9yM3HeOyyCM o/zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=sa1WeKIe; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cb14-v6si13675009plb.178.2018.08.26.15.50.14; Sun, 26 Aug 2018 15:50:29 -0700 (PDT) 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=@google.com header.s=20161025 header.b=sa1WeKIe; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727005AbeH0Ccj (ORCPT + 99 others); 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-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.