From patchwork Mon Jul 24 15:57:06 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kirill A. Shutemov" X-Patchwork-Id: 125090 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9010:0:b0:3e4:2afc:c1 with SMTP id l16csp1912801vqg; Mon, 24 Jul 2023 09:31:01 -0700 (PDT) X-Google-Smtp-Source: APBJJlEaZKyNmNEtPAr6J3JKbK2jz5KLk1ILdMhiZLQjzdzsrLcntGZq0aTLn/T3v5aaUv1kPs69 X-Received: by 2002:aa7:de1a:0:b0:522:2bc7:1c57 with SMTP id h26-20020aa7de1a000000b005222bc71c57mr2930774edv.33.1690216260755; Mon, 24 Jul 2023 09:31:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690216260; cv=none; d=google.com; s=arc-20160816; b=Q9jHSdeEHQVN+4TsCbt02YOeVCKTqpxhq0lukPxPwzjeIOCEVyu99Qf+wGr5qbFPk9 nZSIUwM9O6MAXzqFa7Pu4NrkD3wtMimyollzrhOd9JgtKilNVs2DqapoE5LhTsEdbWhM M7EL9jJPTV5WiNB2V8us/hTi5a63nKhE7gK4TpUe0NB6NgDjpYZCn+vsK1Pzc38MhCDt cpARRsV2qVsMNUm9uNR7uq4RFtaJOSvr48W42rxibEsaMkZA+C2/tQYYpkTZSOhqGLaV 7Bx9difVov8z8/Kt7WnipFrSpFpxZ/u2b7/cMYGis5HBI4T5F+ci5UQVWGDeuwWD1wdf pmFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Y3oDSz7r/mQ9mXFqjT3RdK/ReY6MTrCQVkFQcQpYCV8=; fh=tvvvXxKpgmvZpaJ3quryuqcqx2uu+MjrOigviOlbR+4=; b=CwwUJmKQ+NOescN6PMK4djBc6FtVqhRH9roLL0+SYA+ThfQH2SCBX6EJiBH5/41xor z2poKY5e69RSKsbfiisZUgEIWLwHJDg0bgUzQIn0xtct31XEnSq3pXCHyelQSo/y4vAF nlxDRzjBGSXWprEnSqT/RmPGlxmy8L/XUTGM9znVHtLEpK0Zk/vvvBEMcYCuyAQrXJw4 kwy9ybkBJxXNxD8wInns9JMYHR5R3NMQptp7OK4W+2hkodLwTA9KJpursLUXPgDNZKcl jdUXQuhW0fSnhd0iKRY1GskKSSBCvBPNi7a+2eC69az1Bh3sKOcUqO0weCeNyXS+ST/7 6gzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c9b8WnCZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d8-20020a056402516800b0051e0d77a0fasi6995871ede.647.2023.07.24.09.30.35; Mon, 24 Jul 2023 09:31:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c9b8WnCZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229506AbjGXP5U (ORCPT + 99 others); Mon, 24 Jul 2023 11:57:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231223AbjGXP5R (ORCPT ); Mon, 24 Jul 2023 11:57:17 -0400 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 635758E for ; Mon, 24 Jul 2023 08:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690214236; x=1721750236; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=ECnmIZRK76SlIiCRyT4Ym1T9771ErnINKZxbxO8WZEg=; b=c9b8WnCZcpx1uUmgijjDcZWGLljABRam9TxdJRg8LuOO52/m5pXhSulS Ioi0LvEO1MHW5VEndrEG6fiAG1IFSXMb3kZG8yLrs9o/cVREKuR9ibmog 0zPVfX5Nv3eUB9Mt2nLHRrXE3Zl2NJ23heh7fpWkrz9Z/GwJuaGeOtEU3 y6JGNWimdC2sSHBtpYvx1OOJRf44Tbnlq6lLZZzoWIg2LztsxkW71Frks KOmhDUa796Law1A2FK3ax6UNIoUXrpaNF/ZOqBVYWl0757urIzWchOfvR oGKaKadXJrsrsdCC89/gRwH+pAfkxp1MfQUW+3PmyOLb+5aSu323XYzna A==; X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="357478799" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="357478799" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2023 08:57:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="725770275" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="725770275" Received: from asmaaabd-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.251.208.137]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2023 08:57:13 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 9A2ED103A25; Mon, 24 Jul 2023 18:57:10 +0300 (+03) From: "Kirill A. Shutemov" To: dave.hansen@intel.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" , Yingcong Wu Subject: [PATCH] x86/mm: Fix VDSO and VVAR placement on 5-level paging machines Date: Mon, 24 Jul 2023 18:57:06 +0300 Message-ID: <20230724155706.29900-1-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772320206053796834 X-GMAIL-MSGID: 1772320206053796834 Yingcong has noticed that on 5-level paging machine VDSO and VVAR VMAs are placed above 47-bit border: 8000001a9000-8000001ad000 r--p 00000000 00:00 0 [vvar] 8000001ad000-8000001af000 r-xp 00000000 00:00 0 [vdso] It might confused users who not aware about 5-level paging and expect all userspace addresses to be under 47-bit border. So far I only saw it triggered with ASLR disabled, but I guess it can be also triggered with ASLR enabled if the layout gets randomized just right. The problem happens due to custom placement for the VMAs in the VDSO code: vdso_addr() tries to place them above stack and checks the result against TASK_SIZE_MAX which is wrong. TASK_SIZE_MAX set to 56-bit border on 5-level paging machines. Use DEFAULT_MAP_WINDOW instead. Signed-off-by: Kirill A. Shutemov Reported-by: Yingcong Wu Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace") --- arch/x86/entry/vdso/vma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c index 11a5c68d1218..7645730dc228 100644 --- a/arch/x86/entry/vdso/vma.c +++ b/arch/x86/entry/vdso/vma.c @@ -299,8 +299,8 @@ static unsigned long vdso_addr(unsigned long start, unsigned len) /* Round the lowest possible end address up to a PMD boundary. */ end = (start + len + PMD_SIZE - 1) & PMD_MASK; - if (end >= TASK_SIZE_MAX) - end = TASK_SIZE_MAX; + if (end >= DEFAULT_MAP_WINDOW) + end = DEFAULT_MAP_WINDOW; end -= len; if (end > start) {