From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752266AbcAEP10 (ORCPT ); Tue, 5 Jan 2016 10:27:26 -0500 Received: from mail-bl2on0076.outbound.protection.outlook.com ([65.55.169.76]:3232 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751998AbcAEP1U (ORCPT ); Tue, 5 Jan 2016 10:27:20 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Yuri.Norov@caviumnetworks.com; Date: Tue, 5 Jan 2016 18:26:57 +0300 From: Yury Norov To: Arnd Bergmann CC: Andrew Pinski , Catalin Marinas , "linux-arm-kernel@lists.infradead.org" , LKML , "Kapoor, Prasun" , Andreas Schwab , , Nathan Lynch , Alexander Graf , Alexey Klimov , Jan Dakinevich , Andrew Pinski , David Daney , "Zhangjian (Bamvor)" , Philipp Tomsich , "Joseph S. Myers" , Subject: Re: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Message-ID: <20160105152657.GA31598@yury-N73SV> References: <1450215766-14765-1-git-send-email-ynorov@caviumnetworks.com> <2105480.kqDuemge8n@wuerfel> <2634904.E1fnEZUKo9@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <2634904.E1fnEZUKo9@wuerfel> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [95.143.213.121] X-ClientProxiedBy: AM2PR09CA0040.eurprd09.prod.outlook.com (25.161.22.178) To BY2PR07MB616.namprd07.prod.outlook.com (10.141.222.156) X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB616;2:y/UfrRNORTI4HNOnqd+b40+leIBzwgbu8t8nfb1MjMI0LegkBUkdspRiNUwE8ERZ5Cm9rqVKF/puXZi8ekek8oe/2ARFxQ5chkwsUIf8I5/4+dTsAE97dF+mo3hBbbANBMCbO+1bmONWDaM24INjSg==;3:7EzceobDDW7z8E9yUo8VZdZWbMTyeuZrIV08AUkSQKQZY3lk2mscx8djbJnI9+T9jUdcNFv8Gb+HZYAyIg8KKAVzV9fPqCl7h3sx6gJKsnP3hOiWbBZ+vpWoOgFAO8jG;25:ERqH3GD8QCrpGFYaJqPD0IRuzWmrzdiWOY4FLxkQZOHvoSedYOs1O4tfBdo8dzXJdWYqx9RzAYW8qvtl/7D7Hl8J8OF5S/XQ5Fm1mqkOF1+wJQrB75yOrzSGR5x7JzjmrhcCQhxsD/7CIuBbJS3U3SQP+kINCzuCqbpFb1hCfnUAJ5mHJSzp0AfM7TnF+OYPODzqwHqLiRGDjQouBAbluH4GPO40hACahyeOW3Q1FtBRTWPU8EUtcRzziddB1UxK8gxBdItle3vIbPLfev7bZA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR07MB616; X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB616;20:6AS6Bi2+jfDlbPbzXSBEZWlZYZ3NbQtX2Hn9fm5I+M5buNtI7n1Sg5Y6fG/9+r/1nk/DUQ+VGZJFUa6wQ3Dt2x/7ker09n13GYv5k80/v+alwf+8Gl2++1zsvOU9Ia3Y3tDx1iaCR4TJGxGRU/TFgFTxRGgFmpT3VMa3TXbE1lb49vY1rvbJy6rs4+riZLHov6DpIlrQkFdHssuWeZQjHh/HCBydH35WOkvL7TOiZrz6OYGhbU4wYlJ+yC4QwUSJCOVQSqfd6kaQDc6QOCLwtOnk4XS/wBIcvkeCZolEOyi/9shXOoMfn+yn0ENC0EqzuPJHMf1kR2WpV2KyTg7bVkPwDkfdvjGmdntfQIyc7vZXfTyj+j1JszKigthz82FaYI82lbEWDJv6/iI8j3wljkIeFhgjEPQg5HEadFOIu01xuvU+Aqrsvx0ckxhFuOboTmssC/hJDZGjkTaIGuVY0TfNPIvSsgKkZ4XyWqiKtRNU9CDtXEyL/2fkRMpOFvZyamv5h4JNKTPpQN2LlW8cABqrU+HPhxCihXqRp5pxrbd5Ea/ujXGqWtVrZQGJOOJxQ013WPEVvEFL5YtkNhqeezPEHQgO3PyQmlFqlXGCaE8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001);SRVR:BY2PR07MB616;BCL:0;PCL:0;RULEID:;SRVR:BY2PR07MB616; X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB616;4:/wa/BP48j1aMTtUXmcnziJ8XuZ7rr/4Hd8hqQcbB0w9A1883lrBueKLmEOZDPdddhLMG1ksTJL5jVndJnNIDPYsk9jdeqv1Zgm+1e1ve9NiSBmshMwSqgZWiS0SZBvVsydN+x5aQOPN6djsyrLNvW+MNNyFJDvms43DOt4klDkU86/s+hJBrqXmjQXJWNygVt8IA5lxsLa4VhTgej9I3KBZMFrK6VY7bg18/R3RUL3aVURlLYTUG81gkTHUs7tEl1elOwm0u+LYtSoFTqs/Uh3Az0V8Lqd30NCwWH5nUlcNxT/PB3V+DkSeJFbkQC5LYxEdeJxKBlhbVkWVPUCGyGHfYgR08zBWESBVJNJI5S0/gOZMsYase0s8TWr7FcWuU X-Forefront-PRVS: 0812095267 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6069001)(6009001)(199003)(189002)(76104003)(24454002)(377454003)(83506001)(81156007)(87976001)(4001350100001)(33716001)(97736004)(66066001)(19580405001)(5004730100002)(50986999)(40100003)(46406003)(4326007)(19580395003)(76176999)(122386002)(1076002)(54356999)(5008740100001)(1096002)(47776003)(586003)(189998001)(77096005)(23726003)(106356001)(101416001)(93886004)(50466002)(33656002)(42186005)(97756001)(76506005)(6116002)(3846002)(5001960100002)(92566002)(105586002)(2950100001)(110136002)(60764002);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR07MB616;H:localhost;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;BY2PR07MB616;23:LPIYRoGM46wbBDRUPNShP62vTcO/flBHXNSlpiIj+B?= =?us-ascii?Q?8U9Qs6Zi47CC7ExsbpFtKk19kqGTeVaS49LUzLS8/eTEo91umr75+M8mPXVC?= =?us-ascii?Q?cjTtd3yNep+TlpD9Iv9lMTZhmN/B3sEZ08dcdyBeU83bh9E1rCJQTY4YV8Xx?= =?us-ascii?Q?0eEDolXFkPPagHSfaojyMwZSc1PPokV0FALitYFx/kMYEVbcp2p0ZH5opO29?= =?us-ascii?Q?XzWms6xl28cF3GLigC5RC+05eVQhQIQJIpDu9MWmF9MaSYN27jlmcCVLQfrP?= =?us-ascii?Q?h4ecriTuW3y8d5XtO2GLs0jfZL6R/xL9HggU5lFtpMhEBMHjReZG+rzWJ4f8?= =?us-ascii?Q?Tl7hlXrTujcQ+IcvieYBbLR1WrrDOe5RaxHfcNsZfcnWKAhgi1MBzW4SrzCd?= =?us-ascii?Q?IYFh1ldfIdWqnn2EXPCPTaA7UY/VoZB2xJYd5UL47RmgyGSk38MosRJgfzfa?= =?us-ascii?Q?LHadq0zLiIdh3WyBJYnOKgDN9cmMhCcXSoC8GkmP5tb0ENY8YBMu0EM44FRo?= =?us-ascii?Q?WPXdBG9BBXRXREPtcoAZLqpFFXM3dyPRVGd+xy4npAzfXPyuda8VU0iLp8f1?= =?us-ascii?Q?zXQmTuGjNZZVcxR0ayKg6lBYFsJpDzaZIAJQ95Mm4sCcqbSOi/qlKOTkuhEZ?= =?us-ascii?Q?C9nXsdbYeOZv+9dZsvQCkJ/wjLueIaPjuqOmiuweg7NuNFh1VpStWhoO8Kgz?= =?us-ascii?Q?ncCuF/NiWovkId5lOm89GWxFlb+V9NFhvC3ywUPZ9EU6X4mxPOHYLGx/lZ+H?= =?us-ascii?Q?XfIi6PAHtxJ3RhLZVq977c6B430T2ffYOm/p9VK1mTBZffZWs6D1D6xlWzdJ?= =?us-ascii?Q?N9aE5RSu/gQornQuz3FBEx8LzIxzv5yS57wiRk4plyUhflzxqtNRi0I/937U?= =?us-ascii?Q?dXpZogrTB3ylewMTtvYpcmjf5FaVTcN/NLg4+hA9agOCdDXiZPJvWF7MGEdl?= =?us-ascii?Q?xgFwtWnIXPzmx3eU94T5QEyCOtaRHIr35gS6DWdyuYx5tzSGHxWHV3XlCF5x?= =?us-ascii?Q?UdYklXMfjsRHzfI1ju+2WjasAoUfPZclWCAHAPH72sBQE6/lIOD0zxkrolRI?= =?us-ascii?Q?+DWio4SmoTduD8XMSa9tkLLENGvlXgPELTINjJWe8H733v80QKWWLcMfjiju?= =?us-ascii?Q?vCnUBQGM53j+aA+FrhG18CbWswFbDR7EXAwF+YzseHST+RraYIt8CjjOW6iR?= =?us-ascii?Q?Uvt6g5HZiqEIrc6vepP+iaOiQEQG1IKfVSnX4KOsA7OLKLGkoxJuWzjw=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR07MB616;5:7+qjlS/1zaJ7Hcbgx6k9sg/Rlh2fndNq/d2RqMchE2B2An0Huz8HbqRIPciWyaMo5hG1xWuoyAreGsTWVlWFmh4UOsUNLgLMoz7Idj3HjeXryTwKTtJTvP8OvZyIEj8YLe7Unj33daL/Lq2zTEF2fg==;24:xnovzMW44eBr6ZxknuQvUMYrlUfg81L/uwRkAxj2NuZ+EYUjEpdATfztVlYXT0GpPrkJTo2zldyK2SKOo3UbjAMbV/oDC0ekG2Dv0bU9i0k= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2016 15:27:15.7067 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR07MB616 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 17, 2015 at 09:50:52PM +0100, Arnd Bergmann wrote: > On Thursday 17 December 2015 12:14:20 Andrew Pinski wrote: > > On Thu, Dec 17, 2015 at 12:10 PM, Arnd Bergmann wrote: > > > On Thursday 17 December 2015 18:27:53 Catalin Marinas wrote: > > >> On Wed, Dec 16, 2015 at 12:42:38AM +0300, Yury Norov wrote: > > > > > >> > +#define compat_sys_lookup_dcookie sys_lookup_dcookie > > >> > +#define compat_sys_pread64 sys_pread64 > > >> > +#define compat_sys_pwrite64 sys_pwrite64 > > >> > +#define compat_sys_readahead sys_readahead > > >> > +#define compat_sys_shmat sys_shmat > > >> > > >> I wonder whether we need wrappers (actually, not only for these but > > >> sys_read etc.). These functions take either a pointer or a size_t > > >> argument which are 32-bit with ILP32 but treated as 64-bit by an LP64 > > >> kernel. Can we guarantee that user space zeros the top 32-bit of the > > >> arguments passed here? > > > > > > I'm pretty sure that is safe. I haven't read the calling conventions > > > specification for arm64 ilp32, but usually all function arguments are > > > passed as 64-bit registers with proper sign-extend or zero-extend. > > > > Well (just like LP64 on AARCH64), when passing a 32bit value to a > > function, the upper 32bits are undefined. I ran into this when I was > > debugging the GCC go library on ILP32 (though reproduced with pure C > > code) and the assembly functions inside glibc where pointers are > > passed with the upper 32bits as undefined. > > So we have an issue if called with syscall function or using pure > > assembly to create the syscall functions (which glibc does). > > Ok, I see :-( > > So the calling conventions avoid the problem of being able to set > the upper bits from malicious user space when the kernel assumes they > are zeroed out (we had security bugs in this area, before we introduced > SYSCALL_DEFINEx()), but it means that we need wrappers around each > syscall that takes an argument that is different length between user > and kernel space (as Catalin guessed). arch/s390 has the same problem and > works around it with code in arch/s390/kernel/compat_wrapper.c, while > other architectures (at least powerpc, x86 and tile IIRC, don't know much > about mips, parisc and sparc) don't have the problem because of their > calling conventions. > > This also means that we cannot work around it in glibc at all, because > we have to be able to handle malicious user space, so it has to be > done in the kernel using something similar to what s390 does. > > Arnd So it seems like we (should) have 2 compat modes - with and without access to upper half of register. I'm thinking now on how put it in generic unistd.h less painfull way. Beside of that, I think I almost finished with all current comments. As this issue is not related to ILP32 directly, I think, it's better to show it now, as there is pretty massive rework. What do you think?