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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 1B8DCC4338F for ; Tue, 17 Aug 2021 20:13:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 03E3260EB9 for ; Tue, 17 Aug 2021 20:13:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234111AbhHQUNr (ORCPT ); Tue, 17 Aug 2021 16:13:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233954AbhHQUNq (ORCPT ); Tue, 17 Aug 2021 16:13:46 -0400 Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00507C0613CF for ; Tue, 17 Aug 2021 13:13:12 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id hv22-20020a17090ae416b0290178c579e424so629690pjb.3 for ; Tue, 17 Aug 2021 13:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Qn12Bt9lqkgM5Y8ZA32WQkTEE6ZrP4WykYQaAHbU6bw=; b=ZxGaRtIt0oBicK9RMeZa/zpUJ73fThIcSyHiWhc6pHKYYanyug7eKtat/O3c5kO5mw gHRwyxDy3AneGChipItpQ7AGbSoStDQNCgP17rEZ04NNruirntDKGQ5oArsT6Rf8l5mq FD6bPE7pI1gIqFgVvHXZi5ErvPUUfOpbVmxvOQPjoatcIL9hafPEs2tslUe61IOOA9Ip YYtM22LzKxHubSB8LayLmab6h006bJ483+BiX9MOeLdUAI384Q2kg/BSN0DCsa/q/xBh /bn21nVc5wPJzHgclOptUAYiOUKZWeYsx8VyLDrycaLyO5LmotQtsp+KgX+NYlupgRkS D4zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Qn12Bt9lqkgM5Y8ZA32WQkTEE6ZrP4WykYQaAHbU6bw=; b=j0VcVMK047+v60skIp5oc3A8pcLzctTwlZ+hh4rdgLoqJ0jXQCYu/KJzYbitKgHUvk 0Y0X0IH2CbAspfbeRaBkQDOubhShBVpTX8zU/T9LZzQjezQ39D9zM1JSudwo6itx2Sx3 fbR/JlwEMN3+CNvUSJ+f1WM6q6pmqBJhKtG3PaO+mem2jKUTd+5YmACNVDXaOAZWgdmU 1Wk5Mb8R18WctpWpUhXNHPBGjeqG8EtxuDoLn9iQTzPuQ0SyTdWkWvxpn8eO8EJyDKGN jkMv4KX82Sz9k0GgxX0sdJxvlbKCqW6LGPiVn4M23IaikmGPZkDq7sV2lEcRgxvZT/oi WlTQ== X-Gm-Message-State: AOAM532fRfRYBof5KSonFcMIZr2sbXxcOxUFKk6qv0wFsZ6P5P15xXSO LedaBd2zY/d8hYr6eRLwlWq/bg== X-Google-Smtp-Source: ABdhPJy1rQGRBW8og3iBsiEHWYdl0Z67c7meR88EwdCS+j3BmrvipKWVwAm5pIZRYgXr8OiaPjva8A== X-Received: by 2002:a17:902:db01:b0:12d:ccb0:f8b1 with SMTP id m1-20020a170902db0100b0012dccb0f8b1mr4250158plx.43.1629231192511; Tue, 17 Aug 2021 13:13:12 -0700 (PDT) Received: from smtpclient.apple ([2601:646:c200:1ef2:e1d8:e750:e609:cd1d]) by smtp.gmail.com with ESMTPSA id a2sm4165198pgb.19.2021.08.17.13.13.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Aug 2021 13:13:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v28 09/32] x86/mm: Introduce _PAGE_COW Date: Tue, 17 Aug 2021 13:13:09 -0700 Message-Id: <1A27F5DF-477B-45B7-AD33-CC68D9B7CB89@amacapital.net> References: Cc: "Yu, Yu-cheng" , x86@kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, Arnd Bergmann , Andy Lutomirski , Balbir Singh , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Dave Martin , Weijiang Yang , Pengfei Xu , Haitao Huang , Rick P Edgecombe , "Kirill A . Shutemov" In-Reply-To: To: Borislav Petkov X-Mailer: iPhone Mail (18G82) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Aug 17, 2021, at 12:53 PM, Borislav Petkov wrote: >=20 > =EF=BB=BFOn Tue, Aug 17, 2021 at 11:24:29AM -0700, Yu, Yu-cheng wrote: >> Indeed, this can be looked at in a few ways. We can visualize pte_write(= ) >> as 'CPU can write to it with MOV' or 'CPU can write to it with any opcode= s'. >> Depending on whatever pte_write() is, copy-on-write code can be adjusted >> accordingly. >=20 > Can be? >=20 > I think you should exclude shadow stack pages from being writable > and treat them as read-only. How the CPU writes them is immaterial - > pte/pmd_write() is used by normal kernel code to query whether the page > is writable or not by any instruction - not by the CPU. >=20 > And since normal kernel code cannot write shadow stack pages, then for > that code those pages are read-only. >=20 > If special kernel code using shadow stack management insns needs > to modify a shadow stack, then it can check whether a page is > pte/pmd_shstk() but that code is special anyway. >=20 > Hell, a shadow stack page is (Write=3D0, Dirty=3D1) so calling it writable= > ^^^^^^^ > is simply wrong. But it *is* writable using WRUSS, and it=E2=80=99s also writable by CALL, WR= SS, etc. Now if the mm code tries to write protect it and expects sensible semantics,= the results could be interesting. At the very least, someone would need to v= alidate that RET reading a read only shadow stack page does the right thing.= >=20 > Thx. >=20 > --=20 > Regards/Gruss, > Boris. >=20 > https://people.kernel.org/tglx/notes-about-netiquette