Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1108091imm; Wed, 18 Jul 2018 17:07:26 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc4soenhlqSNSos7FnV99aa1GUqOckoLBorEkctRpws6OPcL4ERxarr3PNyqx3ArexNCdL0 X-Received: by 2002:a62:3ece:: with SMTP id y75-v6mr7281261pfj.7.1531958846898; Wed, 18 Jul 2018 17:07:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531958846; cv=none; d=google.com; s=arc-20160816; b=hSJpUpPufl8xOvn1+amx4J+vkMOTJh71vmNIEkfwCB8jcvH3NGWF1pz+/u2NmR8Z33 FaLs15e72QY3eCih/F+jUMXO6xCCDtTQFbB0N65xRFersjQKmzUyJNG0GEqZaFV5XJpU 0AcuujkcAHun8Fj2tebw6MlW+AY2BpEmdNe7avwSuXr4zNfiQUSag0otZJV5YHnZo0xm ynrVQgf30/nY+J1gQuf+8VPA4Bp/oiRPZqV+fZbDOdeJ2qJGedgBIUXAlg0rCwltm367 7xvakKLPfiYokrB/e3A9WRjRSjxu33hZ49LprguesIRA/biuYvju7fUUP3zQ6JZVMzGP PtDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:to:subject :arc-authentication-results; bh=wAZ3QshgyfXdwGxhmTktGVGYNtsI0hga9f0ED+XQUr4=; b=RTH4A/RW7Lb80PAzNsKKfL9L/x8DiZLctICm4cRGBQN+W1JKnfwDJCf3biw3iXkz9d 49Ae0HnHLtxa8RvedgbDYQuQNZO92D3Z+hs9/64HrSwLKDgVdd6tPqzFO6hq4Erq6EcN TWX1og/LvQPstNIBYvXhAr8QcPrwXgIEQb1mvgtYSqukO7TAx31aaVpkJr0FTTdTT94R QoZFjNbSFsyxVd62HJHHrLyfcfqW2Vgoz/7SHnQkx1FS6/Y3qDwdZ57luKmX7Lg2dfQV 1EXaFs+TCCN5nqiiwsrxZOxnTxKNpR/vI2y+oFLkwxcs5AJYjEwFF95w3Dnwckh0ywKN lXaw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d33-v6si4407675pla.57.2018.07.18.17.07.11; Wed, 18 Jul 2018 17:07:26 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730383AbeGSAq5 (ORCPT + 99 others); Wed, 18 Jul 2018 20:46:57 -0400 Received: from mga18.intel.com ([134.134.136.126]:53967 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728467AbeGSAq5 (ORCPT ); Wed, 18 Jul 2018 20:46:57 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2018 17:06:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,371,1526367600"; d="scan'208";a="73939172" Received: from ray.jf.intel.com (HELO [10.7.201.15]) ([10.7.201.15]) by orsmga001.jf.intel.com with ESMTP; 18 Jul 2018 17:06:36 -0700 Subject: Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack To: Yu-cheng Yu , 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 , Florian Weimer , "H.J. Lu" , Jann Horn , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , "Ravi V. Shankar" , Vedvyas Shanbhogue References: <20180710222639.8241-1-yu-cheng.yu@intel.com> <20180710222639.8241-17-yu-cheng.yu@intel.com> <1531328731.15351.3.camel@intel.com> <45a85b01-e005-8cb6-af96-b23ce9b5fca7@linux.intel.com> <1531868610.3541.21.camel@intel.com> <1531944882.10738.1.camel@intel.com> <3f158401-f0b6-7bf7-48ab-2958354b28ad@linux.intel.com> <1531955428.12385.30.camel@intel.com> From: Dave Hansen Openpgp: preference=signencrypt Autocrypt: addr=dave.hansen@linux.intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzShEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gPGRhdmVAc3I3MS5uZXQ+wsF7BBMBAgAlAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAUCTo3k0QIZAQAKCRBoNZUwcMmSsMO2D/421Xg8pimb9mPzM5N7khT0 2MCnaGssU1T59YPE25kYdx2HntwdO0JA27Wn9xx5zYijOe6B21ufrvsyv42auCO85+oFJWfE K2R/IpLle09GDx5tcEmMAHX6KSxpHmGuJmUPibHVbfep2aCh9lKaDqQR07gXXWK5/yU1Dx0r VVFRaHTasp9fZ9AmY4K9/BSA3VkQ8v3OrxNty3OdsrmTTzO91YszpdbjjEFZK53zXy6tUD2d e1i0kBBS6NLAAsqEtneplz88T/v7MpLmpY30N9gQU3QyRC50jJ7LU9RazMjUQY1WohVsR56d ORqFxS8ChhyJs7BI34vQusYHDTp6PnZHUppb9WIzjeWlC7Jc8lSBDlEWodmqQQgp5+6AfhTD kDv1a+W5+ncq+Uo63WHRiCPuyt4di4/0zo28RVcjtzlGBZtmz2EIC3vUfmoZbO/Gn6EKbYAn rzz3iU/JWV8DwQ+sZSGu0HmvYMt6t5SmqWQo/hyHtA7uF5Wxtu1lCgolSQw4t49ZuOyOnQi5 f8R3nE7lpVCSF1TT+h8kMvFPv3VG7KunyjHr3sEptYxQs4VRxqeirSuyBv1TyxT+LdTm6j4a mulOWf+YtFRAgIYyyN5YOepDEBv4LUM8Tz98lZiNMlFyRMNrsLV6Pv6SxhrMxbT6TNVS5D+6 UorTLotDZKp5+M7BTQRUY85qARAAsgMW71BIXRgxjYNCYQ3Xs8k3TfAvQRbHccky50h99TUY sqdULbsb3KhmY29raw1bgmyM0a4DGS1YKN7qazCDsdQlxIJp9t2YYdBKXVRzPCCsfWe1dK/q 66UVhRPP8EGZ4CmFYuPTxqGY+dGRInxCeap/xzbKdvmPm01Iw3YFjAE4PQ4hTMr/H76KoDbD cq62U50oKC83ca/PRRh2QqEqACvIH4BR7jueAZSPEDnzwxvVgzyeuhwqHY05QRK/wsKuhq7s UuYtmN92Fasbxbw2tbVLZfoidklikvZAmotg0dwcFTjSRGEg0Gr3p/xBzJWNavFZZ95Rj7Et db0lCt0HDSY5q4GMR+SrFbH+jzUY/ZqfGdZCBqo0cdPPp58krVgtIGR+ja2Mkva6ah94/oQN lnCOw3udS+Eb/aRcM6detZr7XOngvxsWolBrhwTQFT9D2NH6ryAuvKd6yyAFt3/e7r+HHtkU kOy27D7IpjngqP+b4EumELI/NxPgIqT69PQmo9IZaI/oRaKorYnDaZrMXViqDrFdD37XELwQ gmLoSm2VfbOYY7fap/AhPOgOYOSqg3/Nxcapv71yoBzRRxOc4FxmZ65mn+q3rEM27yRztBW9 AnCKIc66T2i92HqXCw6AgoBJRjBkI3QnEkPgohQkZdAb8o9WGVKpfmZKbYBo4pEAEQEAAcLB XwQYAQIACQUCVGPOagIbDAAKCRBoNZUwcMmSsJeCEACCh7P/aaOLKWQxcnw47p4phIVR6pVL e4IEdR7Jf7ZL00s3vKSNT+nRqdl1ugJx9Ymsp8kXKMk9GSfmZpuMQB9c6io1qZc6nW/3TtvK pNGz7KPPtaDzvKA4S5tfrWPnDr7n15AU5vsIZvgMjU42gkbemkjJwP0B1RkifIK60yQqAAlT YZ14P0dIPdIPIlfEPiAWcg5BtLQU4Wg3cNQdpWrCJ1E3m/RIlXy/2Y3YOVVohfSy+4kvvYU3 lXUdPb04UPw4VWwjcVZPg7cgR7Izion61bGHqVqURgSALt2yvHl7cr68NYoFkzbNsGsye9ft M9ozM23JSgMkRylPSXTeh5JIK9pz2+etco3AfLCKtaRVysjvpysukmWMTrx8QnI5Nn5MOlJj 1Ov4/50JY9pXzgIDVSrgy6LYSMc4vKZ3QfCY7ipLRORyalFDF3j5AGCMRENJjHPD6O7bl3Xo 4DzMID+8eucbXxKiNEbs21IqBZbbKdY1GkcEGTE7AnkA3Y6YB7I/j9mQ3hCgm5muJuhM/2Fr OPsw5tV/LmQ5GXH0JQ/TZXWygyRFyyI2FqNTx4WHqUn3yFj8rwTAU1tluRUYyeLy0ayUlKBH ybj0N71vWO936MqP6haFERzuPAIpxj2ezwu0xb1GjTk4ynna6h5GjnKgdfOWoRtoWndMZxbA z5cecg== Message-ID: Date: Wed, 18 Jul 2018 17:06:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1531955428.12385.30.camel@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> -static inline bool can_follow_write_pte(pte_t pte, unsigned int flags) >>> +static inline bool can_follow_write(pte_t pte, unsigned int flags, >>> +     struct vm_area_struct *vma) >>>  { >>> - return pte_write(pte) || >>> - ((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte)); >>> + if (!is_shstk_mapping(vma->vm_flags)) { >>> + if (pte_write(pte)) >>> + return true; >> Let me see if I can say this another way. >> >> The bigger issue is that these patches change the semantics of >> pte_write().  Before these patches, it meant that you *MUST* have this >> bit set to write to the page controlled by the PTE.  Now, it means: you >> can write if this bit is set *OR* the shadowstack bit combination is set. > > Here, we only figure out (1) if the page is pointed by a writable PTE; or > (2) if the page is pointed by a RO PTE (data or SHSTK) and it has been > copied and it still exists.  We are not trying to > determine if the > SHSTK PTE is writable (we know it is not). Please think about the big picture. I'm not just talking about this patch, but about every use of pte_write() in the kernel. >> That's the fundamental problem.  We need some code in the kernel that >> logically represents the concept of "is this PTE a shadowstack PTE or a >> PTE with the write bit set", and we will call that pte_write(), or maybe >> pte_writable(). >> >> You *have* to somehow rectify this situation.  We can absolutely no >> leave pte_write() in its current, ambiguous state where it has no real >> meaning or where it is used to mean _both_ things depending on context. > > True, the processor can always write to a page through a shadow stack > PTE, but it must do that with a CALL instruction.  Can we define a  > write operation as: MOV r1, *(r2).  Then we don't have any doubt on > pte_write() any more. No, we can't just move the target. :) You can define it this way, but then you also need to go to every spot in the kernel that calls pte_write() (and _PAGE_RW in fact) and audit it to ensure it means "mov ..." and not push.