Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754839AbbDOPtv (ORCPT ); Wed, 15 Apr 2015 11:49:51 -0400 Received: from foss.arm.com ([217.140.101.70]:36349 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755542AbbDOPtn (ORCPT ); Wed, 15 Apr 2015 11:49:43 -0400 Date: Wed, 15 Apr 2015 16:49:33 +0100 From: Catalin Marinas To: "Dr. Philipp Tomsich" Cc: Andreas Kraschitzer , Arnd Bergmann , linux-kernel@vger.kernel.org, Andrew Pinski , Kumar Sankaran , Benedikt Huber , linux-arm-kernel , Christoph Muellner Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Message-ID: <20150415154933.GH22741@localhost> References: <17844053.vZiPCu4un3@wuerfel> <20150414144702.GD14546@e104818-lin.cambridge.arm.com> <2485404.lBlHmzQPKN@wuerfel> <20150415112224.GA26099@e104818-lin.cambridge.arm.com> <721B7D5F-0A9A-45B7-8036-730ED54FB3AB@theobroma-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <721B7D5F-0A9A-45B7-8036-730ED54FB3AB@theobroma-systems.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1404 Lines: 29 On Wed, Apr 15, 2015 at 01:50:51PM +0200, Dr. Philipp Tomsich wrote: > On 15 Apr 2015, at 13:22, Catalin Marinas wrote: > > I think you are right. I was more thinking of those routed directly to > > the native (non-compat) syscalls. We would need to make sure the return > > value (X0 being the only register not restored on return from exception) > > has the top 32-bit part zeroed. > > As the kernel is LP64 and will thus attempt to return a 64bit return value, the > high bits should be properly sign-extended in all cases. > > The problem (posed by procedure call standard) of information leakage could > manifest itself only, if the kernel tried to return something smaller than 64 bits… > in that case, we can the problem would already exhibit for the LP64 ABI. > > For the ILP32 implementation, I’ll thus assume that all LP64 ABI calls reused > are clean in this regard. Yes. All the compat_sys_* are defined to return a long, so even if ILP32 user space treats it as 32-bit, there is no information leak because of the kernel's sign-extension. So just a false alarm, we can consider this part sorted. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/