Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2209774imm; Sat, 13 Oct 2018 12:38:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV63iQ1SyXbyycmBCFXXLKE3lB1NJj7g7nXu6hamhRvuBoQ50DqFUHEViDGFIscnYC3um8JXl X-Received: by 2002:a17:902:246a:: with SMTP id m39-v6mr10904474plg.57.1539459487227; Sat, 13 Oct 2018 12:38:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539459487; cv=none; d=google.com; s=arc-20160816; b=CacRW3rtpYiQ1QUsHw29sDOBaCjr79hxEOiRfZEM2X1aOA8PePz6aQco0zOY0tML2P JN1u3EEOGcepPR0EP6CANLvc01vFhltOgyUzIVewniJSC1W0fhImiYYsIuwLl4/LhXax KrRozYAadRNluqWSWAPfDlXrEkylvHRbgmCzXqNGw63/GXr4QXrXBiABXMHHzZPQt2PO 9xv7VHPTSYYZRC2dBYOVnkuEaNTVV44s0xbSDawJm3aSbvwuQJpATNfD4r8WXlLqXwaN XG9DKR0nS06pe08Qc2jqRBNaB8vk+OZVLTLC6MG3lS/lMF6d3GPR0kcTJTrV2YC2t6Jw H/bQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=IB0dDp12Jf0ZeNJvQ0OICfXMiDXerl76Z99vxAuNG9A=; b=TyB/kbTcU7GGHfbYKE/oJ1JEjdTFjCdCAe+xvgANa423mkLRlRuKjMg0L58tc9gK56 3KLew6mii57v2Xm8+oZBkpetutXfrzp7vamzjWPQSdB5nYg82mHnEefKsBMGyq0U+nVH ptXHULBQPFeUB9cCxHm3OfbHT7IvBH0tEYRQZHcob46e0uCBmgicbx/45cOTyT9oyYj/ QkwicSDie7xZWvkP70KvMPM53XXDgoh5u+eDGVdD2st3zlaHgZgzAaPuTDpcPqZnNiIU oGmaUx7iisk7CPFElNGRQZKMgmgbdwM3JWXW/c9nF0nulJBtQOTyAUJqs6/KwjfGoHVQ RKCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=uBYWNRNk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f189-v6si1702292pfa.65.2018.10.13.12.37.52; Sat, 13 Oct 2018 12:38:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=uBYWNRNk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726882AbeJNDOz (ORCPT + 99 others); Sat, 13 Oct 2018 23:14:55 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:34345 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726837AbeJNDOy (ORCPT ); Sat, 13 Oct 2018 23:14:54 -0400 Received: by mail-wm1-f67.google.com with SMTP id z25-v6so20221324wmf.1 for ; Sat, 13 Oct 2018 12:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IB0dDp12Jf0ZeNJvQ0OICfXMiDXerl76Z99vxAuNG9A=; b=uBYWNRNkHCWLtPoK9/uZ+UylZsLKL5D+tG1rUIwdM8hp/6QbLCHJa3iyfq+wb9wGRO iDCrInMooCfWkB1S8lXak//59rGflC+qeMlwoai1SCJ4IrjlEcX7AWU1If8ueJh7mFdb DRsvbWtC0aM/UgVbmp3iICuVSoih0YZtSXv7x268OzznD+W2mGRNcdLNH4Qk4KIigllR IBm8iAXfxcqnD0mR+sQnhB9Qs5VDjW+zGT3Ht9Z+xEx6Su6hEcoh009CDYZi33zuczTt 50ovhMLBcNmM0vLXDAhr+Z6RN84GlMhYq1NxdJ48vyI4lhPtCLOyczZDlkKit+WNSO2d hlLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IB0dDp12Jf0ZeNJvQ0OICfXMiDXerl76Z99vxAuNG9A=; b=UX+fPgEGO7/TnjtkngtVfl2RwLs6xJygta2o0h9PsK14OsvjTfVtjjtmtX+qe04hoz 4ybA2wBWWyGLct7pxIX++dFshqE0KsAYQ705IFmWRSbxQ0Z8oHTDL65qAt/E3TqDRTco UewVKtYLWd5FUIJzIi33GfAebFZV+vL1Pr3ZzreWQ8uHryB9J1RBxIXoG0Q42/vtqmVH b/rYWrOhN2prGLVuA24+0i6aLTJa0owmtk4TBuEoRLnX2Y9ylKfgkJk47sArCphE1uR2 uR5ePzGNvSzS/GyIJv4DI9DXwVFbVRGG092sTjp5g82mG2Tarwu0G5AzZRM1stkpsTul a88Q== X-Gm-Message-State: ABuFfoiYC9zhgY1ui0Ksp/XmtSLTn0aWmjjxSwM6UZwS4vqURH9BImX3 HPbAQNbL7XcejbLVCQIiznVdlwm5g+tVVgMaD7NkWw== X-Received: by 2002:a1c:d4b:: with SMTP id 72-v6mr9345378wmn.102.1539459393753; Sat, 13 Oct 2018 12:36:33 -0700 (PDT) MIME-Version: 1.0 References: <20180516081910.10067-1-ynorov@caviumnetworks.com> In-Reply-To: <20180516081910.10067-1-ynorov@caviumnetworks.com> From: Andy Lutomirski Date: Sat, 13 Oct 2018 12:36:21 -0700 Message-ID: Subject: Re: [PATCH v9 00/24] ILP32 for ARM64 To: ynorov@caviumnetworks.com Cc: Catalin Marinas , Arnd Bergmann , linux-arm-kernel , LKML , linux-doc@vger.kernel.org, linux-arch , Linux API , Adam Borowski , Alexander Graf , klimov.linux@gmail.com, schwab@suse.de, Andrew Pinski , bamv2005@gmail.com, Chris Metcalf , christoph.muellner@theobroma-systems.com, Dave Martin , "David S. Miller" , Florian Weimer , Geert Uytterhoeven , Heiko Carstens , James Hogan , James Morse , "Joseph S. Myers" , linyongting@huawei.com, manuel.montezelo@gmail.com, Mark Brown , Martin Schwidefsky , Maxim Kuvyrkov , Nathan Lynch , philipp.tomsich@theobroma-systems.com, Prasun.Kapoor@caviumnetworks.com, ramana.gcc@googlemail.com, sellcey@caviumnetworks.com, szabolcs.nagy@arm.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 16, 2018 at 1:19 AM Yury Norov wrote: > > This series enables AARCH64 with ILP32 mode. > > As supporting work, it introduces ARCH_32BIT_OFF_T configuration > option that is enabled for existing 32-bit architectures but disabled > for new arches (so 64-bit off_t userspace type is used by new userspace). > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64. A few thoughts: 1. I've never been able to shake the feeling that x32 should not need kernel support at all. As far as I can tell, the kernel support is an enormous amount of code and complexity to deal with exactly two issues. First, ILP32 only has 32-bit pointers, so there needs to be a way to tell the kernel to only use the lower 4 GB of user address space. That part is easy. Second, ILP32 user code is highly unlikely to end up with the same struct layout as ILP64 code. The latter seems like it should be solved entirely in userspace by adding a way to annotate a structure as being a kernel ABI structure and getting the toolchain to lay it out as if it were ILP64 even though the target is ILP32. 2. I think you should make a conscious decision as to whether the ILP32-ness of a syscall is a property of the task or of the syscall. On x86, x32-ness is a property of the syscall, but historically it also got rather entangled with the state of the task, and the result was a mess. It looks like you're making it be a property of the task, which is fine, but you're making it impossible for very clever ILP32 libraries to include little ILP64 stubs that do fancy things with full 64-bit syscalls. 3. Make very certain that you aren't exploitable by malicious processes that set the high bits in ILP32 syscall args. x86 compat has issues like that in the past.