From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 3E0D67D8D5 for ; Sat, 13 Oct 2018 19:36:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726831AbeJNDO4 (ORCPT ); Sat, 13 Oct 2018 23:14:56 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:53025 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726846AbeJNDOz (ORCPT ); Sat, 13 Oct 2018 23:14:55 -0400 Received: by mail-wm1-f66.google.com with SMTP id 189-v6so15212290wmw.2 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=FbpCdPNTF0WDY9dYCbd403zOk2+YdAcFg+yzknY/Gw1KGGL6ByUcg1tVmwbJRkRipZ 6+IkI/a8oV+BQI8JMrmx1XFGRPQGSZdMqZ33j2CpflNr6t35mFhLsoqQRhFCYgFj+WOn 4rWQ2cbgsC6j1nDEW6aa4qDzGjMXxDRopuFwAC9HJq5cgNpw+AAfn5bhElA4d2xsSbic e9ugG7BSV+MLUoWKSfd5P8+yJpuSrY3W7vYXZXZt4xRWFb8X0dATldLlo9Gs35Qm9PHU Lg9j+yYQPCG/nc6pHZGX9fFLtJz45A29QweP+cP5eDxV4E/p79qQFju3qhaVwO/kavqS UgzQ== X-Gm-Message-State: ABuFfohp/twYssOTOgpYzUVxJjZKnK9HRCj522GUOtD8EWfYF9dH0P9R jA0zAIlXUlPLUYsfbrAlvabS1EKSbnJVvLHYY4jcjg== X-Google-Smtp-Source: ACcGV61ulHaUaGgXMLFCkeOKbViTrIIKrwfSR83PifPtlorZhlo/4VIHrA06ghfe/bqGgooHbdDdm41sJyALGFttN0o= 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-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@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.