From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932730AbdCFOkN (ORCPT ); Mon, 6 Mar 2017 09:40:13 -0500 Received: from mail-he1eur01on0096.outbound.protection.outlook.com ([104.47.0.96]:2896 "EHLO EUR01-HE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753324AbdCFOi7 (ORCPT ); Mon, 6 Mar 2017 09:38:59 -0500 Authentication-Results: vger.kernel.org; dkim=none (message not signed) header.d=none;vger.kernel.org; dmarc=none action=none header.from=virtuozzo.com; From: Dmitry Safonov To: CC: <0x7f454c46@gmail.com>, Dmitry Safonov , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Borislav Petkov , , , Cyrill Gorcunov , "Kirill A. Shutemov" Subject: [PATCHv6 4/5] x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) Date: Mon, 6 Mar 2017 17:17:20 +0300 Message-ID: <20170306141721.9188-5-dsafonov@virtuozzo.com> X-Mailer: git-send-email 2.11.1 In-Reply-To: <20170306141721.9188-1-dsafonov@virtuozzo.com> References: <20170306141721.9188-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: DB6PR1001CA0021.EURPRD10.PROD.OUTLOOK.COM (10.171.79.31) To VI1PR0801MB1742.eurprd08.prod.outlook.com (10.168.67.20) X-MS-Office365-Filtering-Correlation-Id: 5a30f9d5-07c9-4800-b80d-08d4649c120c X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR0801MB1742; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1742;3:8kqKoKhA5nsqD0tND4V2DPeGqDyFomGj/legKVd+gY/N4Qiz12AsIxtFDhHfW0lAxV7g3ntCNkpjRvJrsx3NbGheXt8ItiSVi9TEXZfRNeZ2+lGukVO8ZX67Pw/3hV9UkK+f3VLjj1ciaFr+K5OWGDqIcA2nFHgDkPFlZHJEQ2G9YPJUCv192ETS5bYf4ICEyuBspICmfzkj7kghT5/W1YirhddLAvY5NAetxJZ0aXWmai5QQGCHZs8MO9z5hR7e5EAD72UQXFG1DSw6cF2iOg==;25:HV1ILC6A11p2EC6YxBQYM11eCGswIZ1La59CghmpT+I61tzwOyikMdOvx0mdeZKQCB4cpZNL8LsbJOiHlzUOQKO2r0o3HeuNqjjdf4xkgMWD7py7zNhRzLXnkzSYNXm+tvG8/PpQnhqZimhhfQErv2hE9yEdqv3WydJm49p+ONAxYBDkV/L3e+YAScmO1/dNqtmEIgoJPCV6G2cdjhr4xYCeV5njonOc7PTHWr9BwfGGcwqtXVRe5t0TJOIRIXdZXF5E04dpYr/tFylqZxpjqIic46aj4+91S2Gjo+FBiRDfIvreq2hU5u2DUqXdsv8wbr/NJz+b+edX8iWcX/ZWVI0oopDmLRuT84YmeI8cBwnDTcP6f+pOebYfqw622zM2DtltOmaiYzrsixaz35q89gjb+Mha5nU+3a+a0BpVUVOfFSnss4U8FGQsSX78W3rYXkjhHYWV5Eq1G4BGwg6e8w== X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1742;31:9+ikoys7BMviemtCP4d9KGW2TG8tIwS6CKbu5Sy/MDelTxvJg2hHqIq8efHVBwLbsSRfMKsa9xUBHcfMatGMN1vjaGnQyD0979fDPvvo7Ubo2eBlN/GAhW1cLLBZhZS1jkogu318BPo63p7j8HNAsKjgaf0ndnCRq+597tLuJAVuUQrzjDk4/YE+hTner856xKISIEnJDUsZXNoHbkiJtVl9I+PrLtVBXeRDvubMm4ZJcK9oOofuINBXByExvb5r;20:dMgSQXoMAfdEZC9U2YyiLt3XjO0D8vCuUt3aft64J1NRYA+VbatjOIJl7GD25crNJdWsFL6lue1dENNf9uIEGoyVOb5pYnu4I9gZ8QX3hxFxzQ4IHBwaoz1/vuY+zcuwHrsC3DhbPynEwoFuLg/gJZs7pG36Q2DT/RmKeQ/3o7087qkq5nWW67XwUTp456ObV8I84FBKD4fjGfu3XE392KC+/AiVmpqBHMd6d1XNaj/zixVgoscJyH+grGbncQTDrhSYO+419J6f2OuqOicNCmPXASw2aXlJjfiTJ7qb6e54GwNJARX3lUYA3+oaE+o8wimfLJZm9AsVwrKR4QqYqn4Zc+GaMvQg+Du+33W/sHes7XQHh/Y+7oc6gpbgKRLF6c+Sy4hfs50PZ2nmkaU7Y+2dMf1mAgaP7bcSxfgn69w= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(6072148);SRVR:VI1PR0801MB1742;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0801MB1742; X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1742;4:M7zsf2xNn3LlTl/6JtlGDjJuhnGrbVi0bz5Sf6omxm3fjSGsAaJghOqaS2GouZOYvg9IJTGGt7mGHOH542Mv5Wy/Otze7iuOjHMMjy6Q4ajcp+d4JoX4fnLCjwymtKxevKhRZaY53gBGmuUm+R/H/OU5kFVj1SfVRDQAdA/asXZdESUcBScsCRqK/mZMFF1AIGQEQGFjrohTa2YzHUjtD3z2ucm0zPPukUdLM1Goez49cLEHzfCQT9i7VjuXP4ls9oss52lyhfx4G7C84Hsyzp4GVhliTWLukMzrRqh0MK6CAIjX9f5KX9Znu7XARrC76hkUdL/cs/X6k7YFLrQw0IKpk4GGnHF9fgyAyQ93w3lF9ufQl+7kHjm0ANpNg8kFaX4oD1ystkf0x4h2NMNHa4jPw8kVX0eWXv/e+Im792c8r8ToL/30jgxSU4Z+E/xVecNxdh9DgP863H0eM6S01i/m5SdGOZtQLQ/XjictDHwGT/j7PaB/7ZBJpxS7V2WagG2VyqDj+ZGn/RX7B1eYoDU5BEGStWleLTtA70TKEeqXyQgB8VtQDgTa+TySfTJa6d4ain+zq9WHfC2GMkMSatRbLrYe/F5SRG973gmlBQo= X-Forefront-PRVS: 0238AEEDB0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(2906002)(110136004)(6916009)(2950100002)(305945005)(8676002)(53416004)(38730400002)(81166006)(6512007)(50466002)(42186005)(7416002)(1076002)(7736002)(5660300001)(53936002)(5003940100001)(76176999)(50986999)(48376002)(25786008)(66066001)(54906002)(86362001)(92566002)(189998001)(50226002)(2351001)(3846002)(4326008)(47776003)(33646002)(36756003)(6116002)(6506006)(6486002);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0801MB1742;H:dsafonov.sw.ru;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;VI1PR0801MB1742;23:tqVakEKl/Eag+SyiMdLIwlhFeJCq+QOEffUix1l?= =?us-ascii?Q?teBzqSlw2lt9Fyq7YkaMpYc2xgObV1h2j+Cf5dzDUNryK/MaZ6EEvd4BXnd4?= =?us-ascii?Q?tOa8kK5z93XGDPrs+2biLwRJIow55x6KlaiqOqfCFOvYJBDeMQZXuHyEiKpK?= =?us-ascii?Q?FWE6tisrJ8V7i1x5X+wDM6QK/KWMLkelyDb8dVPwBmx52bKDCnGnhkrDWNEk?= =?us-ascii?Q?YUnB9RaY8KQm+CFzEgnSBeG0xUnNJuhOKE1P5eawCinlxZ0Ry+TRP3b9fXOS?= =?us-ascii?Q?YLn/EqJUX6/OpNejcFk/yu1S9kJB4Qsfi7q3UCVnNL0zJff6SD3AzjYCLVJH?= =?us-ascii?Q?SU7dnGFOc42gWL5CiI++05SBLIW0voLooLb7ypvJhcc6RvjeFv9fRtn2XJkQ?= =?us-ascii?Q?z1Bq7E+soFZNAYpUxjFfAEKwVmUdzJhOR6ceR0Nm0ONAi9jio/KkTZcl1Xkf?= =?us-ascii?Q?azHB2xqrAckMUUX37k0nRnO4kHgAVrCXc/+pDOvrJBPncjh344Pi0xY6lKxW?= =?us-ascii?Q?R00O11wMb/bjgQ52SxhLwAV0ArtjZNjYMxdIkOhi6gDfiWm8wUMLFFSNGr8y?= =?us-ascii?Q?ny2pKSQVw0+AtILlIPFFpG+LmpA4rRkcYF7HeVDaFRawkl6+QPzkwqWdWPyk?= =?us-ascii?Q?4PtGsJkI+/da1ILBCvexMX2ZSgEIR0UvuUySAQw+pIN4ygpDpm33HbFa9Lnc?= =?us-ascii?Q?PpVmToYvcuizESMIE3okqDW6yes29PW01GmxPqT4u1NJQLWSVRAByLKGoaVy?= =?us-ascii?Q?MwYY2Cw/H2XC7/Q5olMkBKMaTVkJSyc7/FCft6c5H7YAOGNdUPmvQQldLAUR?= =?us-ascii?Q?q5lrFZXKk1lpm8W7edd8JgWnBKwr0b4xxwlEOkldLCwchJYrp2fF57zLTwf9?= =?us-ascii?Q?qiXonmY8vYHWmfhbZ2w6I31OUlWHM6Qxp+CwRDbnjjwGwPztbOjOZ2d3i45B?= =?us-ascii?Q?bWWW6CmYqMhgvCadMAsG6gy7Pultqbw3RyWSbO+atazCJrP4VItEU/0L/jC6?= =?us-ascii?Q?5E151wg2M+nZ6COtUrlQSIpy8?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1742;6:U5BJbR2tEKGM6d4/PBIq0eE6/1TsCcyjfux/cMKX+LEwib0oKlDFJc0+sxIH9g/XDXVA3wz1Ps4B5VFFp657TUJKc7mtSSy1/JlaR2T9KueqZSionrMwYlk5ykEeqDng6V70akoUVEm/NGucrTOz0IL1dIWHsiEbX7cle6gMtbjYdL0uHgyZ1RdaXE3Hbzu2xnGumJgj87zAOLr6igg9hLc1WjBnEbWEQABIXDcR65zWURkuM11VM3bzptXmL7Qhy70fy3zR+6wUHJm+zgVxe5JXOJFSBo8ne4/PezXIqTIsM+rSdGQ6Fng6vHE9NYhuel0Ki8X3SWOGEaUx7005hFXdfdDeyIEtWG8Ns3RdVYDxfj4JbyEJK062xtgcOJnelZuD/b7y8pQbpzrHHG/Njg==;5:lTFIFRqydwcRtXQcWmrfAWT4BdgEnQ3gL0Gh2NNL6qa4df2vD1u5/Y89ePis6vrjWYd5wn64+pX1OMxLVC9zJgvmZ/uGFR7ka3NfS2fro02stZVZ7YFORmrbxnbxr53MlRZv82RqUePANBXAzqaWgg==;24:i1BGY0V0pFYOh+xF1xzXvaQslbOicvrBuul3mMj11IjYXIo5uNd6eeEyv5rfDPy+MDwoU/XuZJwBGF067kJ09/VtsCP/FiWQ0vVVu5gBtlE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;VI1PR0801MB1742;7:vGY0MjMhC0JXg/ZhsadgtVkULqK7bHFZtU3C7CgjKZSOdIKWp8tXbG1DFCo1rsyULJBxIQNnCtIhmaoV7yDaIOwUzKODfKaWPkHjnRHVq2r//vB3iGlS96ho7N1BfdAzY4/Zspwi7ZLFofz5YDY+eGGJRfff8SIYM6zbKqKGY0gdF9xhLU6qbl/dsVTDGHqyA1/1S1V6wY3CPhGjOgWL4ezY15QcWpQETMN0KUF8901wHJeHXZEX2RWSJyIU1T8X4Nh2e62hOdHOYn1SRf8K6USZUbYaNOvrcA9EBWcMVGvuAA+RLQNLcBfO+JK+mrl7xUzRd9/7ME3XflxeAu9cVA==;20:kSsMQzxB/YweotOrhbGxi86AT3QVasgBA0IdvRdlmoxrX0JDgNL1JwOrj9H78LOw2FUCtTCN7qRZtjScZAlKIBxkpm6UwEw6K4MuW/+eW2GF+yjzzgIuq5XFn4FOzEn6Cac8Iz35A+IEEOERNOon9CDkhyBjvhBpaaXpg1Dt050= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Mar 2017 14:21:23.2860 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1742 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Result of mmap() calls with MAP_32BIT flag at this moment depends on thread flag TIF_ADDR32, which is set during exec() for 32-bit apps. It's broken as the behavior of mmap() shouldn't depend on exec-ed application's bitness. Instead, it should check the bitness of mmap() syscall. How it worked before: o for 32-bit compatible binaries it is completely ignored. Which was fine when there were one mmap_base, computed for 32-bit syscalls. After introducing mmap_compat_base 64-bit syscalls do use computed for 64-bit syscalls mmap_base, which means that we can allocate 64-bit address with 64-bit syscall in application launched from 32-bit compatible binary. And ignoring this flag is not expected behavior. o for 64-bit ELFs it forces legacy bottom-up allocations and 1Gb address space restriction for allocations: [0x40000000, 0x80000000) - look at find_start_end(). Which means that it was wrongly handled for 32-bit syscalls - they don't need nor this restriction nor legacy mmap (as we try to keep 32-bit syscalls behavior the same independently of native/compat mode of ELF being executed). Changed mmap() behavior for MAP_32BIT flag the way that for 32-bit syscalls it will be always ignored and for 64-bit syscalls it'll always return 32-bit pointer restricted with 1Gb adress space, independently of the binary's bitness of executed application. Signed-off-by: Dmitry Safonov --- arch/x86/kernel/sys_x86_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c index c54817baabc7..63e89dfc808a 100644 --- a/arch/x86/kernel/sys_x86_64.c +++ b/arch/x86/kernel/sys_x86_64.c @@ -115,7 +115,7 @@ static unsigned long get_mmap_base(int is_legacy) static void find_start_end(unsigned long flags, unsigned long *begin, unsigned long *end) { - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) { + if (!in_compat_syscall() && (flags & MAP_32BIT)) { /* This is usually used needed to map code in small model, so it needs to be in the first 31bit. Limit it to that. This means we need to move the @@ -191,7 +191,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, return addr; /* for MAP_32BIT mappings we force the legacy mmap base */ - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) + if (!in_compat_syscall() && (flags & MAP_32BIT)) goto bottomup; /* requesting a specific address */ -- 2.11.1 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) by kanga.kvack.org (Postfix) with ESMTP id ECEE76B03CC for ; Mon, 6 Mar 2017 09:21:26 -0500 (EST) Received: by mail-it0-f72.google.com with SMTP id m27so79251253iti.7 for ; Mon, 06 Mar 2017 06:21:26 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0113.outbound.protection.outlook.com. [104.47.2.113]) by mx.google.com with ESMTPS id f64si8480850iof.200.2017.03.06.06.21.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Mar 2017 06:21:26 -0800 (PST) From: Dmitry Safonov Subject: [PATCHv6 4/5] x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) Date: Mon, 6 Mar 2017 17:17:20 +0300 Message-ID: <20170306141721.9188-5-dsafonov@virtuozzo.com> In-Reply-To: <20170306141721.9188-1-dsafonov@virtuozzo.com> References: <20170306141721.9188-1-dsafonov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org Cc: 0x7f454c46@gmail.com, Dmitry Safonov , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Borislav Petkov , x86@kernel.org, linux-mm@kvack.org, Cyrill Gorcunov , "Kirill A. Shutemov" Result of mmap() calls with MAP_32BIT flag at this moment depends on thread flag TIF_ADDR32, which is set during exec() for 32-bit apps. It's broken as the behavior of mmap() shouldn't depend on exec-ed application's bitness. Instead, it should check the bitness of mmap() syscall. How it worked before: o for 32-bit compatible binaries it is completely ignored. Which was fine when there were one mmap_base, computed for 32-bit syscalls. After introducing mmap_compat_base 64-bit syscalls do use computed for 64-bit syscalls mmap_base, which means that we can allocate 64-bit address with 64-bit syscall in application launched from 32-bit compatible binary. And ignoring this flag is not expected behavior. o for 64-bit ELFs it forces legacy bottom-up allocations and 1Gb address space restriction for allocations: [0x40000000, 0x80000000) - look at find_start_end(). Which means that it was wrongly handled for 32-bit syscalls - they don't need nor this restriction nor legacy mmap (as we try to keep 32-bit syscalls behavior the same independently of native/compat mode of ELF being executed). Changed mmap() behavior for MAP_32BIT flag the way that for 32-bit syscalls it will be always ignored and for 64-bit syscalls it'll always return 32-bit pointer restricted with 1Gb adress space, independently of the binary's bitness of executed application. Signed-off-by: Dmitry Safonov --- arch/x86/kernel/sys_x86_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c index c54817baabc7..63e89dfc808a 100644 --- a/arch/x86/kernel/sys_x86_64.c +++ b/arch/x86/kernel/sys_x86_64.c @@ -115,7 +115,7 @@ static unsigned long get_mmap_base(int is_legacy) static void find_start_end(unsigned long flags, unsigned long *begin, unsigned long *end) { - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) { + if (!in_compat_syscall() && (flags & MAP_32BIT)) { /* This is usually used needed to map code in small model, so it needs to be in the first 31bit. Limit it to that. This means we need to move the @@ -191,7 +191,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, return addr; /* for MAP_32BIT mappings we force the legacy mmap base */ - if (!test_thread_flag(TIF_ADDR32) && (flags & MAP_32BIT)) + if (!in_compat_syscall() && (flags & MAP_32BIT)) goto bottomup; /* requesting a specific address */ -- 2.11.1 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org