From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753384AbdA3MFK (ORCPT ); Mon, 30 Jan 2017 07:05:10 -0500 Received: from mail-eopbgr40112.outbound.protection.outlook.com ([40.107.4.112]:47211 "EHLO EUR03-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753369AbdA3ME6 (ORCPT ); Mon, 30 Jan 2017 07:04:58 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=dsafonov@virtuozzo.com; From: Dmitry Safonov To: CC: <0x7f454c46@gmail.com>, Dmitry Safonov , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , Borislav Petkov , , , Shuah Khan , Subject: [PATCHv4 0/5] Fix compatible mmap() return pointer over 4Gb Date: Mon, 30 Jan 2017 15:04:27 +0300 Message-ID: <20170130120432.6716-1-dsafonov@virtuozzo.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: VI1P194CA0011.EURP194.PROD.OUTLOOK.COM (10.175.178.21) To HE1PR0801MB1740.eurprd08.prod.outlook.com (10.168.150.7) X-MS-Office365-Filtering-Correlation-Id: 00ea3f3d-7aa0-4589-795e-08d449083008 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR0801MB1740; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1740;3:2/TbxpOgnIxrF0PMn3ZyedsG+NvYEdLtWu7iDtlZ3P3E6BZmaI3rAMOVkwRTRsmsJLbuOragtyxN2xofWe/Kaxpk2Sgibzf3C9Kae1AHM9Ze3sw0V4KkvwHFfsjLm9V3fxN6dZO4uwR6G/GDIz75MCdHUS/otg7Wzivn1Jg+BzW4A8q6c6Q1m4D5ET/cv95JFzWYWJYiQsCrMbfSFmrgaMgI7DhzbifHRBq+pkMr8n0TnUcVgEvc5G8WV+Z+cyE4hHwg11/ZnjIXnIuFNUIPAA==;25:nbyBm+TYmnXBosMR6NAtUxkQkcrnpyjE5S5fSQBTJiJLeuKeQptT09UFyrvtLAJV2C7N7FTmtCWjTYdHpi1mihk8eRNt8WFm7k0qvo7gUpxioOW5hnBrUfxDdlb99QATo1SxZV4NDVfHw0Lgi+ZrOZON6fs2oflU2J3VZKmNF5W0wfnp8XzAuYqFUiu/JkjFbOyfimTf8Z+lplyJco1IqPgh7Khtj5dlZfBfGBaDFezDMNmWd9xZ9A6aMfxEXo/vNRONuPmgADVO6Tx2jsgH/mZ5hbKDHz0s83r0YebUuHxD7+FsRxqTeWgCnfi9YVnW0IZDjTKiKK1oEEzEjTJI1M3dJPRtwlMokFh5zkfPO6l/TLXPZQzDQYM0E9dwZDA4HNOKa8u8H/gI5LwUA7ApRdvFenDiNIZCvv3VibCVhoKeqc/Q+b/S86H79cbivDVn36j+9hX+QyN5DpxHE+35xg== X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1740;31:fqUv9rDxp2hDwa1ZMfcoDKeVz/O6My5uDep5wh7JqjM++hxf2x7x9sKYM9f0d5JSYb5G8E+FZvn+BJO0x/DtknW7xUFDdLZMsKvparfdrz2sCvNcrHuCt2NmVKZsaVFEiPaJ6n8eGzpQORC/nys95g11rw7NTiBp4URrOiL4Gp6mSbIxvBVJWJUQpRObFcQ9oBuaHh6lelWHx6ivMSjUiVNVAxXPJGa+/ws8BNWFCyKMGbKXvLq87gtH3W3ZV1fnLKNp7P9BGWOAaygz8Rhe8Q==;20:O4Re3W8BTvqx+JE/VgZiXcnGen/qGHmTR7LdIYCxhTuR/E8JUO5BYwE9EOsPcSpstMKOgXsnxGaZtibW8jCmhHHrfTyQB2fK9fgJPMktHUhc2ysF9av8tpds0QAe3EpUYa52YjYbMXjz0JrmHNpD6zJ7DYR7P+LxSx0t0lknoXZdKMDKwzxBtjXwwU2+PTQLplzZPO1IvMt6+A8rIQGadTm443PQjixTra+VpLxTElY4c7wdBV7zOcOMh3rdRkvs X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558021)(6072148);SRVR:HE1PR0801MB1740;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1740; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1740;4:PTozxzpN+azlxz1vZ/9j4pzKTWF3jMpDGTSZXc4lWvU3prj81bKoNVZ2NEx/2MQu3Hl3WQ9TTtrVY8Rh9e1ebu87Dysq0xU2gkvWYvXwo8vYAcQI00u6R6pMXI542d2iM8mFxookI1KNgN7boYdwj+fA7B9CM/rt+KRzvtBFE0z9s7Xe7AvuMkguNMwGRPLkiuwUsfc/jECizEv7PDB0yo35KA+JYGrGDU/B8JGHMCuILbL4J3/mtXrR143sNzWn/XRzFTkMP0aCpdSvzLCIG+LJTcEe5Qylhe06g7QNuOnRFbhZ9jHIBYpLFsziohDJXAP0yTIpTMNSSDTlcX1SpZ/hYyOQmowJCU/xcHDkzt2D4JR/d95ZDWb1GDohRoMEnnMCLY6HB1JjGsix0Y4CB+Ilf+VbOeMwxAUAQBHvMyh7V2bXyJSY6+Fr0DpEJC6FlqtUpgsYzVc57U+tXSu/058MUuFMeH66NPA1kOkXVoz7c/4qnYLueCuV/IE2icAsQPD7BsMODXXUKXNv6uxXMLLNDb7Up3LogE7Phsjh+QjQ82R/BxLlu4NZ3J5+SOad8FjR5Rbd+Jwem4mt49C0vi/n57jRUzzRgPLPdcgryS4= X-Forefront-PRVS: 0203C93D51 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(199003)(189002)(7736002)(92566002)(189998001)(110136003)(53936002)(33646002)(4326007)(39060400001)(1076002)(53416004)(38730400001)(68736007)(97736004)(5003940100001)(6486002)(8676002)(305945005)(2906002)(6666003)(105586002)(50466002)(6506006)(6916009)(48376002)(106356001)(69596002)(86362001)(50986999)(47776003)(54906002)(6512007)(36756003)(6306002)(66066001)(2351001)(42186005)(81166006)(3846002)(6116002)(81156014)(25786008)(50226002)(101416001)(5660300001)(7416002)(6606295002);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1740;H:dsafonov.sw.ru;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;HE1PR0801MB1740;23:jVJVye3dHAoeXch1vDwdJNy1werRpK+w/X2l6th?= =?us-ascii?Q?j3pwiZh1zpDLANYUt2oWcBao1A4xn+SAFvS+5ioFgf2kT3KKM24jS2gEMG+e?= =?us-ascii?Q?/zG4BNBi3EvlDjH2OxXdo+7UVjPKmpDHYQNlBzSWEh3vh1owZcFv8db0VBNG?= =?us-ascii?Q?NnlieHf+XQt8BOKhRnOucMcW876/6/HBkqQVogWEWPqNUPraLRFED9F8oEdY?= =?us-ascii?Q?no+1uCdzB4HnrkmBNND4tX3nT4gB/egx75CTtJQUWKFBfx9RhZDDvkCvKjYe?= =?us-ascii?Q?iYtWWWvIShD381DtBmJnAQgciSSbsRl+QTqcIbMjTp6Ps4yCNg5PPN1D+U0v?= =?us-ascii?Q?erXlj31PgAdbS9CQiHlJ7eHKpqXf5OxIbjQW9DdOag9hZY9IVbfUKLYTEIHo?= =?us-ascii?Q?sJVK2Bt/lG/DsKi1of06i2x8BioUycLF5jPn+3xQT400WWHItquDE1oCrUen?= =?us-ascii?Q?X4YQS/g/TUiac6B1LcYSnQ8481QEtUMprxgnROPY290So1iwUUeEkN1+/sdQ?= =?us-ascii?Q?kQOjY0zinUczIYaREJBYP7bbq71EXkpWlo79YEC/gpEAZ6/UwL7+DmNPglzr?= =?us-ascii?Q?oSLQB3pyi3YfuNHNBZLg2JEHtogT5xSYsVQIA98QHWGwumiXv8VBRAGPonrw?= =?us-ascii?Q?zrvm9n7Kjeq/Hq69kbvhXi6i+7iRiPZfZUzo9bhHgibMTe9ZyNA97qLf7pgY?= =?us-ascii?Q?kYE3+1ZZvglpkq9MgtucXMDoeMB1NgxeXVgl+pPCilitlSesqXwMJS1SRPqv?= =?us-ascii?Q?gTK0kMTabzEDG7Q9GnTaFlPV7mlxJll3hhZGubbHazUiB2XnWDvhRCchgIUa?= =?us-ascii?Q?XoKzGAd2asBUaVD05mpXr4EP4q7SQFlcugGwVwBKL+EyndeCh8Gf1JuGH45H?= =?us-ascii?Q?eUI0vBsPfLXq7zP9pjKt/CPaCw/su6zkQOBavUg9LPkekFrWG5450fL4iNH4?= =?us-ascii?Q?Eo9DAg/Sd/bFacbro1ckKdMJyRrLqF1mXvo8Q9Q3lKLxFF/pheJQdfI/bXyG?= =?us-ascii?Q?02j/ZD7B8NdepiyJyHklPFro9OrLw71Mhn3Z70pGYBSf+TBlLLFJP+O3nzHb?= =?us-ascii?Q?1sN3QNJ/jtyBbnuXn82qF+3xI3aDf0OZ26aBYJL0vL6Pl7lvYCRXo8blIq56?= =?us-ascii?Q?QV96l7jWlqN9DgDNSfgBpJXHKycFxvjcAVPo96ryvToCnFknJSBQH0VsyV1P?= =?us-ascii?Q?q7gDU886FXzd2X8OJ8MjnObjeGl3MoIj8kD5GLCbjVtua2LzxxVIKFWY5h0j?= =?us-ascii?Q?zX+9riuLu+DSiqI9Djq0=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1740;6:Os9LHYIO+0jPEBP79NbUdxeE1iet5Cuf+55j59J78qC36TzpbaaDXw1betXFCBCLXVR8hz+AbRtnZkCSHN7LfA/fO2uCy2v0+fO2zVAEaiqOGPxWjbLJZlPREk2JWFosjeVEWxoeiiZ5DUZdln9BTIk2xgf5HDg/A/PQOPpwjpBm/fydpu484UN9DN3Qpec35Q6im3tpeX6qglla0EzMQHrnLYj5PPDVmJJfzaTzK3dvQm6tNBE3rnkaE8SEaeNhQE+k1su+ZmP3ELYNfcNbYElUUnBs2Tz2MC2W+Dv+d9CzQV5lUeM37aSexnPeI0SpfLu///M6OswpgXYgntVn+yhGuyN3fVBkfTDbTgiaoCsFyeU+0ZxJp9jmbq7fqgMOdbqTjReqtqkiKOKNsvKUX3f9X0DT6YEssEzWwAClmfk=;5:tn32ctakf9hUmZAl26xvFMNiA6uywpoFaj74TNcV1CTu5KWFegUtMke9SkoDZ1EKHXigQWrkzJf6LJsB7XqCWt25OvD4VPdtcUZNPZX2H+0VvcOiL7wEj757XtCMaV2H12Zvd7vzNLSE50LfmCaHb6WkoUuxU4N6PSQhkQcNoEQ=;24:eJxFd5a0iK/WF7ZcpFW0Nu51a1MttaEDLaTpiOYWEzw2j7F1O8HWNHThgilspzJF9d2WDA9/NYTCT89mwDoXTdW4f/dFHZffEYXvRa0klVo= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1740;7:W0kZ30HoZmF+7lDKxDsh/YhL2bB/tq6M+Mz4FKcsmwFuFtXFDek3nqiizf/FY23ePwmO2ITC2nastxDMbYqiAIAeMFazpfRHu8D31/7fh8jV61ZondMt6ACi0HhMCEOxQhgbXb3oFJx2X9Ho/cHy6KOJxl41GgpmbFBQWeKSGx2ORVUOGWk5PelauUg+TwNKIlMpDO2xHKoBRpVbX/6PCTcTNXRypNyatV7klwfeyj+yvOuLljKMcjt8wgwc9Mbbh5I7gKhL0EVi991MZtpzTdlYZyLQcOTT0P7SxLQ6mGszSd89NDbqzSh5NN2HSkJPf3eMTFSHifNFmxm0bQiyaX2m5UFpri8KiYoVmobHqKqF1baunPrXPEAn9biWXfTeMT+nxwJCzpVddRP/BYMTPZAySlsRBt/q5tqTU0h98e5Oj8jx6O81ba7Z47ytLhr52k4MFDGc2MSmfkDioGbcGg==;20:qBNvYTMNfd8cLhDrjZDfnD7k2RVaE5tZLgnoMsBHDWwNW+8x5EZiTiR/6yiCx+s2HHe2pG8VBxY9j6YAnYduMv8CP4VPy4WCH/fuQXKmOVU+Ylk7kJqvzCRio9PsMrAHz7nkFK3m6DFsJmNhthMO031MUTlBY1AMpMnbVfpIW7s= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2017 12:04:46.6958 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1740 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Changes since v3: - fixed usage of 64-bit random mask for 32-bit mm->mmap_compat_base, during introducing mmap_compat{_legacy,}_base Changes since v2: - don't distinguish native and compat tasks by TIF_ADDR32, introduced mmap_compat{_legacy,}_base which allows to treat them the same - fixed kbuild errors Changes since v1: - Recalculate mmap_base instead of using max possible virtual address for compat/native syscall. That will make policy for allocation the same in 32-bit binaries and in 32-bit syscalls in 64-bit binaries. I need this because sys_mmap() in restored 32-bit process shouldn't hit the stack area. - Fixed mmap() with MAP_32BIT flag in the same usecases - used in_compat_syscall() helper rather TS_COMPAT check (Andy noticed) - introduced find_top() helper as suggested by Andy to simplify code - fixed test error-handeling: it checked the result of sys_mmap() with MMAP_FAILED, which is not correct, as it calls raw syscall - now checks return value to be aligned to PAGE_SIZE. Description from v1 [2]: A fix for bug in mmap() that I referenced in [1]. Also selftest for it. I would like to mark the fix as for stable v4.9 kernel if it'll be accepted, as I try to support compatible 32-bit C/R after v4.9 and working compatible mmap() is really wanted there. [1]: https://marc.info/?l=linux-kernel&m=148311451525315 [2]: https://marc.info/?l=linux-kernel&m=148415888707662 Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Borislav Petkov Cc: x86@kernel.org Cc: linux-mm@kvack.org Dmitry Safonov (5): x86/mm: split arch_mmap_rnd() on compat/native versions x86/mm: introduce mmap{,_legacy}_base x86/mm: fix 32-bit mmap() for 64-bit ELF x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) selftests/x86: add test to check compat mmap() return addr arch/Kconfig | 7 + arch/x86/Kconfig | 1 + arch/x86/include/asm/elf.h | 4 +- arch/x86/include/asm/processor.h | 3 +- arch/x86/kernel/sys_x86_64.c | 32 +++- arch/x86/mm/mmap.c | 89 +++++++---- include/linux/mm_types.h | 5 + tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/test_compat_mmap.c | 208 +++++++++++++++++++++++++ 9 files changed, 311 insertions(+), 40 deletions(-) create mode 100644 tools/testing/selftests/x86/test_compat_mmap.c -- 2.11.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by kanga.kvack.org (Postfix) with ESMTP id 285EA6B0038 for ; Mon, 30 Jan 2017 07:04:54 -0500 (EST) Received: by mail-oi0-f72.google.com with SMTP id j82so371135642oih.6 for ; Mon, 30 Jan 2017 04:04:54 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40109.outbound.protection.outlook.com. [40.107.4.109]) by mx.google.com with ESMTPS id r188si5335530oib.142.2017.01.30.04.04.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 30 Jan 2017 04:04:53 -0800 (PST) From: Dmitry Safonov Subject: [PATCHv4 0/5] Fix compatible mmap() return pointer over 4Gb Date: Mon, 30 Jan 2017 15:04:27 +0300 Message-ID: <20170130120432.6716-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, Shuah Khan , linux-kselftest@vger.kernel.org Changes since v3: - fixed usage of 64-bit random mask for 32-bit mm->mmap_compat_base, during introducing mmap_compat{_legacy,}_base Changes since v2: - don't distinguish native and compat tasks by TIF_ADDR32, introduced mmap_compat{_legacy,}_base which allows to treat them the same - fixed kbuild errors Changes since v1: - Recalculate mmap_base instead of using max possible virtual address for compat/native syscall. That will make policy for allocation the same in 32-bit binaries and in 32-bit syscalls in 64-bit binaries. I need this because sys_mmap() in restored 32-bit process shouldn't hit the stack area. - Fixed mmap() with MAP_32BIT flag in the same usecases - used in_compat_syscall() helper rather TS_COMPAT check (Andy noticed) - introduced find_top() helper as suggested by Andy to simplify code - fixed test error-handeling: it checked the result of sys_mmap() with MMAP_FAILED, which is not correct, as it calls raw syscall - now checks return value to be aligned to PAGE_SIZE. Description from v1 [2]: A fix for bug in mmap() that I referenced in [1]. Also selftest for it. I would like to mark the fix as for stable v4.9 kernel if it'll be accepted, as I try to support compatible 32-bit C/R after v4.9 and working compatible mmap() is really wanted there. [1]: https://marc.info/?l=linux-kernel&m=148311451525315 [2]: https://marc.info/?l=linux-kernel&m=148415888707662 Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Andy Lutomirski Cc: Borislav Petkov Cc: x86@kernel.org Cc: linux-mm@kvack.org Dmitry Safonov (5): x86/mm: split arch_mmap_rnd() on compat/native versions x86/mm: introduce mmap{,_legacy}_base x86/mm: fix 32-bit mmap() for 64-bit ELF x86/mm: check in_compat_syscall() instead TIF_ADDR32 for mmap(MAP_32BIT) selftests/x86: add test to check compat mmap() return addr arch/Kconfig | 7 + arch/x86/Kconfig | 1 + arch/x86/include/asm/elf.h | 4 +- arch/x86/include/asm/processor.h | 3 +- arch/x86/kernel/sys_x86_64.c | 32 +++- arch/x86/mm/mmap.c | 89 +++++++---- include/linux/mm_types.h | 5 + tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/test_compat_mmap.c | 208 +++++++++++++++++++++++++ 9 files changed, 311 insertions(+), 40 deletions(-) create mode 100644 tools/testing/selftests/x86/test_compat_mmap.c -- 2.11.0 -- 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