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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 58B92C282DA for ; Wed, 17 Apr 2019 19:49:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1B971205C9 for ; Wed, 17 Apr 2019 19:49:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555530563; bh=un9JngdqTRaqtIrvykfJj/MFL9SGLhvcacMgNjMe4H4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=k0kgic5aqlKCpJsSMAdwxEfUHJUo4JdhHhvoS9FCTrmMU2OAkNp3lnEJtEo+idfnI RvOVYdIlQ5ntpPFfLlZ83vs4ruWYJCrGS4ae1IxntcZdARJkm3zxjWTws6FVutsRnr wgHOVTeYNbZkK1flYN/vNVA8gq1h/8WT12JVWovU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387423AbfDQTtV (ORCPT ); Wed, 17 Apr 2019 15:49:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:50836 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729779AbfDQTtU (ORCPT ); Wed, 17 Apr 2019 15:49:20 -0400 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 6CEEA2183E for ; Wed, 17 Apr 2019 19:49:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1555530559; bh=un9JngdqTRaqtIrvykfJj/MFL9SGLhvcacMgNjMe4H4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=bkgqQKeudwW/ql7cXAWlWd7+w2wYtPSx6J91uUy4ZcxjeDA+8lal1Pkj/qr69xaG/ WaXdLduXEkACl++4dtx/SX7Zph9S7Ix/sxHMbDFm88OskSxAWn3IEKh+NRXMidwD3K 9T8r8nGq3B3hHgBGtMaf10n4GQfaCrB4rbSIaRJ0= Received: by mail-wr1-f49.google.com with SMTP id o12so4060302wrn.2 for ; Wed, 17 Apr 2019 12:49:19 -0700 (PDT) X-Gm-Message-State: APjAAAVXd/XsaDPJ01TpgBrHPXW6LcO7/C+haK/WNjl3z8TgXYasftm7 hMcUWaD2wkODTGqhmJVRNG4PdOjbKqIdTyNsJc6Q8Q== X-Google-Smtp-Source: APXvYqwslPQOOCGBluAyQ370prOUXMhL8otOt2EJTpreLpaaBphk3bN4/Rpkbdm1dLisarFpIiIJANwuHztMcLGcdZw= X-Received: by 2002:adf:f344:: with SMTP id e4mr23917370wrp.77.1555530556240; Wed, 17 Apr 2019 12:49:16 -0700 (PDT) MIME-Version: 1.0 References: <20190417161042.GA43453@gmail.com> <20190417170918.GA68678@gmail.com> <8d314750-251c-7e6a-7002-5df2462ada6b@oracle.com> In-Reply-To: <8d314750-251c-7e6a-7002-5df2462ada6b@oracle.com> From: Andy Lutomirski Date: Wed, 17 Apr 2019 12:49:04 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO) To: Khalid Aziz Cc: Ingo Molnar , Juerg Haefliger , Tycho Andersen , jsteckli@amazon.de, Kees Cook , Konrad Rzeszutek Wilk , Juerg Haefliger , deepa.srinivasan@oracle.com, chris hyser , Tyler Hicks , "Woodhouse, David" , Andrew Cooper , Jon Masters , Boris Ostrovsky , iommu@lists.linux-foundation.org, X86 ML , linux-arm-kernel , "open list:DOCUMENTATION" , LKML , Linux-MM , LSM List , Khalid Aziz , Linus Torvalds , Andrew Morton , Thomas Gleixner , Andy Lutomirski , Peter Zijlstra , Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Arjan van de Ven , Greg Kroah-Hartman Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Wed, Apr 17, 2019 at 10:33 AM Khalid Aziz wrote: > > On 4/17/19 11:09 AM, Ingo Molnar wrote: > > > > * Khalid Aziz wrote: > > > >>> I.e. the original motivation of the XPFO patches was to prevent execution > >>> of direct kernel mappings. Is this motivation still present if those > >>> mappings are non-executable? > >>> > >>> (Sorry if this has been asked and answered in previous discussions.) > >> > >> Hi Ingo, > >> > >> That is a good question. Because of the cost of XPFO, we have to be very > >> sure we need this protection. The paper from Vasileios, Michalis and > >> Angelos - , > >> does go into how ret2dir attacks can bypass SMAP/SMEP in sections 6.1 > >> and 6.2. > > > > So it would be nice if you could generally summarize external arguments > > when defending a patchset, instead of me having to dig through a PDF > > which not only causes me to spend time that you probably already spent > > reading that PDF, but I might also interpret it incorrectly. ;-) > > Sorry, you are right. Even though that paper explains it well, a summary > is always useful. > > > > > The PDF you cited says this: > > > > "Unfortunately, as shown in Table 1, the W^X prop-erty is not enforced > > in many platforms, including x86-64. In our example, the content of > > user address 0xBEEF000 is also accessible through kernel address > > 0xFFFF87FF9F080000 as plain, executable code." > > > > Is this actually true of modern x86-64 kernels? We've locked down W^X > > protections in general. > > > > I.e. this conclusion: > > > > "Therefore, by simply overwriting kfptr with 0xFFFF87FF9F080000 and > > triggering the kernel to dereference it, an attacker can directly > > execute shell code with kernel privileges." > > > > ... appears to be predicated on imperfect W^X protections on the x86-64 > > kernel. > > > > Do such holes exist on the latest x86-64 kernel? If yes, is there a > > reason to believe that these W^X holes cannot be fixed, or that any fix > > would be more expensive than XPFO? > > Even if physmap is not executable, return-oriented programming (ROP) can > still be used to launch an attack. Instead of placing executable code at > user address 0xBEEF000, attacker can place an ROP payload there. kfptr > is then overwritten to point to a stack-pivoting gadget. Using the > physmap address aliasing, the ROP payload becomes kernel-mode stack. The > execution can then be hijacked upon execution of ret instruction. This > is a gist of the subsection titled "Non-executable physmap" under > section 6.2 and it looked convincing enough to me. If you have a > different take on this, I am very interested in your point of view. My issue with all this is that XPFO is really very expensive. I think that, if we're going to seriously consider upstreaming expensive exploit mitigations like this, we should consider others first, in particular CFI techniques. grsecurity's RAP would be a great start. I also proposed using a gcc plugin (or upstream gcc feature) to add some instrumentation to any code that pops RSP to verify that the resulting (unsigned) change in RSP is between 0 and THREAD_SIZE bytes. This will make ROP quite a bit harder.