Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1749479pxv; Fri, 2 Jul 2021 11:11:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycgONapqv955U6Audq83uS3Kp81AU8554qzl739WHIkgruV8V1HRET0Xtl6xyzKr00CwYc X-Received: by 2002:a17:906:a3d7:: with SMTP id ca23mr1104016ejb.176.1625249502999; Fri, 02 Jul 2021 11:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625249502; cv=none; d=google.com; s=arc-20160816; b=vkQFK0z9rQ9JOhBH2nsFdQQiZ/wEc3deqAApDl3j5zimDYVoVjIRUgqihqob0ZRIMf dIzVwueYTPAmxIpdHiZvuSL3iJ8Xzcsk3OzpuwTJZ8MDY4pJ0+kunQMoTz47Jgzwv2De 5d3XYnfCbp0hLu5YTNyveGPCKuy1q1/ulvqNkHenV6uteZsCtTBTa0h8juN5fe9XHaK4 hjxFzda1jVIKknqLYaXams80u9xjSIxfd8u/MkwkNB66654goqNuqpcarktuzpG4iCLJ 1DZeRmImT5ospLl2BcmSJJZOI9zy+VYt7peLerVPX5szaFBpclNRP7LZyXTjvfb2xnOY ttsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=oMUyVVAvMFJrr6EX64aXQFDIL61RBU3XqCzFnhQssG4=; b=FuoDwG1rVDECqIwz5Xj0QULyaVSosUSw7bNk9NNaBGn1xUqqjpfS8VCzbInsO3JRED 746HjRDbpnHi23gBK8dPaLTGbN5mm3hy7elU9UhaFXDrFqMHmWtPugpuMhG9g7DpiThP LxSgzIv1muk0nQpQtU1E0Q8qOqHDtQ2+9Xem41HI5D4d/sjk3zuMqOrHoo+dH+kIcpeH G+efgaT4B+xjNV5ehPiGbMgpac9h6YT7bsUXKgsPd96ASRqjI9BwChvvkB+4XiLBJ8TB GHnv36v/D+0fwPBndF3a/fhjmwcidCEVeEv6TCdqnJGAd2auVp5jCi3f2sd8c/gj052I DGzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Y72HmJuu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id em20si4048962ejc.0.2021.07.02.11.11.17; Fri, 02 Jul 2021 11:11:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Y72HmJuu; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbhGBSKf (ORCPT + 99 others); Fri, 2 Jul 2021 14:10:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229455AbhGBSKe (ORCPT ); Fri, 2 Jul 2021 14:10:34 -0400 Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4F88DC061762; Fri, 2 Jul 2021 11:08:01 -0700 (PDT) Received: by mail-qv1-xf36.google.com with SMTP id cn9so3421147qvb.3; Fri, 02 Jul 2021 11:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=oMUyVVAvMFJrr6EX64aXQFDIL61RBU3XqCzFnhQssG4=; b=Y72HmJuuDzX0TavkIgDtuWaUuSwMJkubIKxudISMvENuqlMV7QZt/2aiZeGyHcf2MI ulU4pDQ4tJDJJt7EIy54MeEZBkEBLNr3UQJe8/H32CAhahYn8ho/L0WjMMkVML8yRK4z +9JWP9OMx+Kac+MX8q0h/PTd0vbWY7JygBDhaFEkCeEmnYopLRSKFgNc2S/yIP440gdA YL4/7cS6JKjazM7+eWskuVpYJjmGTteIH/fsL5DnkhI8zbraldhezgHFn34673kP5Pvc 5xYEHBxk/+fRudXN3PeyN6Ss8NG1VMPhokMX8J/J3mmhyrIS35iE0ZcvYfjbRDV0tTE6 tt4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=oMUyVVAvMFJrr6EX64aXQFDIL61RBU3XqCzFnhQssG4=; b=sprS2iM2Rvc2DBh50zJggptOXHIPCGuugGcaLn5gqgzcIRsyvO8gIu6WuCAWam4bXk iSlA5gg0mcpNzh/ojN7sON7Z92XjH4kjMidxCjz4IPuoC+ZhJK9yUCAeL2tUwksxADTp DZKoIhHY+4Tf+c7bBRDj9eVn3bvp1X+h6Sf4bRwvscmQgCjuzYSJHAqObzNHt0iOBhPX 2o2ZrnKm76+pWR7Ugc4jvTrjCJzZxOGJy4qXar830KR31Dt9R1Tv75zW8Epi7szchgqD Imhdt+liFJj5Yt0aiiYGxnrJFxNOPyL7oAAlYCkDPDQxiNMhkBUkK9f1wJUtjfTO8MCZ MmmQ== X-Gm-Message-State: AOAM533DCPWyvH587Xj4QfOz0Cro7eoQ1cyYciwqMv4nZHxnrPDupGir IVDt4mJU7CFuY09qRyUaQ6A= X-Received: by 2002:ad4:4666:: with SMTP id z6mr707715qvv.60.1625249280326; Fri, 02 Jul 2021 11:08:00 -0700 (PDT) Received: from localhost ([207.98.216.60]) by smtp.gmail.com with ESMTPSA id f10sm1496462qtq.48.2021.07.02.11.07.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jul 2021 11:07:59 -0700 (PDT) Date: Fri, 2 Jul 2021 11:07:58 -0700 From: Yury Norov To: Catalin Marinas , Arnd Bergmann , linux-audit/audit-kernel Cc: linux-audit/audit-kernel , Mention , Xiongfeng Wang , bobo.shaobowang@huawei.com, "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-doc@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-api@vger.kernel.org" , Adam Borowski , Alexander Graf , Alexey Klimov , Andreas Schwab , Andrew Pinski , Bamvor Zhangjian , Chris Metcalf , Christoph Muellner , Dave Martin , "David S . Miller" , Florian Weimer , Geert Uytterhoeven , Heiko Carstens , James Hogan , James Morse , Joseph Myers , Lin Yongting , Manuel Montezelo , Mark Brown , Martin Schwidefsky , Maxim Kuvyrkov , Nathan_Lynch , Philipp Tomsich , Prasun Kapoor , Ramana Radhakrishnan , Steve Ellcey , Szabolcs Nagy Subject: Re: [linux-audit/audit-kernel] BUG: audit_classify_syscall() fails to properly handle 64-bit syscalls when executing as 32-bit application on ARM (#131) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 01, 2021 at 05:08:45AM -0700, Paul Moore wrote: [CC ILP32 list] Weiyuchen wrote: > I use ILP32 program on 5.10 kernel Recently, and I find that I can't recored log in some case, here is a example: The last supported kernel version by me is 5.2. Did you port the ilp32 to 5.10 by youself? Can you please share this work? > I set one rule on the system: > >> auditctl -w /etc/shadow -p wa -k test > > my test program's core func is: > >> open("/etc/shadow", O_WRONLY | O_APPEND); > > when I use 64 bit program to access /etc/shadow, I can get audit log rightly > but when I use ILP32 program, I can't get any audit log > > I analyse this problem for days, and I find it's due to this commit: > >> 0fe4141ba63a5dfd425c6d2dd9d8cbafd3497946 >> ....... >> #define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE) >> +#define AUDIT_ARCH_AARCH64ILP32 (EM_AARCH64|__AUDIT_ARCH_LE) >> #define AUDIT_ARCH_ALPHA (EM_ALPHA|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE) >> #define AUDIT_ARCH_ARCOMPACT (EM_ARCOMPACT|__AUDIT_ARCH_LE) >> #define AUDIT_ARCH_ARCOMPACTBE (EM_ARCOMPACT) I cannot see this commit in Linux mainline. Can you point me to the exact git repo? > Beacuse of ILP32 program use 64 bit syscall in most case > (according to the arm ilp32 Documents:) > when audit enter audit_classify_syscall function, it turns to a branch different from the kernel without AUDIT_ARCH_AARCH64ILP32 defination, however the syscall num on both kernel is same, so audit can't recognize the 64 bit syscall num when it runs to 32ILP branch I've never seen this bug before. Can you please check if it exists in 4.9 or 5.2 versions? Can you share the full reproducer and/or corresponding test in LTP? --- Paul Moore wrote: > >From the ILP32 whitepaper: > > What is ILP32? > > > > The ARMv8 architecture supports 32-bit and 64-bit instruction sets (AArch32 and AArch64 > respectively), both use 32-bit instruction encodings but with different register lengths and data > type sizes. > > > > ILP32 is intended for use where, for whatever reason, it is beneficial to use int, long and pointer > represented as 32-bit values. This could be for performance or legacy 32-bit compatibility > reasons. > > > > Linux on AArch64 uses LP64 as its standard data model, where Long and Pointer are 64-bit, > Ints are 32-bit. > > > > AArch64-ILP32 uses the AArch64 instruction set coupled with a data model where Int, Long > and Pointer are 32-bit. > > ... which means that ILP32 is basically the ARM version of x32. Which is pretty much just the worst thing ever; x32 needed to die a painful death and my initial thought is that ILP32 deserves the same fate. ARM64/ILP32 is not a version of x32. ABI concept and implementation are different. I understand your criticism about x32, but this project is closer to mips, spark or power compatibility layers. In the kernel we have more than 10 implementations of compatibility layers, and only one causes serious troubles, AFAIK. > @weiyuchen we will add this to the queue to investigate but it may take a while; if you are interested in working on it you are always welcome to submit patches. > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > https://github.com/linux-audit/audit-kernel/issues/131#issuecomment-872191450 To Catalin, Arnd: At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer actively use and develop arm64/ilp32. I receive feedback / bugrepotrs on ilp32 every 4-6 month. Is that enough for you to reconsider including the project into the mainline? For me, having different versions of ILP32 is more dangerous in this situation, than upstreaming the project and fixing 2-3 bugs a year. Thanks, Yury