Message-ID: <YN9V/qM0mxIYXt3h@yury-ThinkPad>
Date:   Fri, 2 Jul 2021 11:07:58 -0700
From:   Yury Norov <yury.norov@...il.com>
To:     Catalin Marinas <catalin.marinas@....com>,
        Arnd Bergmann <arnd@...db.de>,
        linux-audit/audit-kernel 
        <reply+ADSN7RXLQ62LNLD2MK5HFHF65GIU3EVBNHHDPMBXHU@...ly.github.com>
Cc:     linux-audit/audit-kernel <audit-kernel@...eply.github.com>,
        Mention <mention@...eply.github.com>,
        Xiongfeng Wang <wangxiongfeng2@...wei.com>,
        bobo.shaobowang@...wei.com,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        Adam Borowski <kilobyte@...band.pl>,
        Alexander Graf <agraf@...e.de>,
        Alexey Klimov <klimov.linux@...il.com>,
        Andreas Schwab <schwab@...e.de>,
        Andrew Pinski <pinskia@...il.com>,
        Bamvor Zhangjian <bamv2005@...il.com>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Christoph Muellner <christoph.muellner@...obroma-systems.com>,
        Dave Martin <Dave.Martin@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Florian Weimer <fweimer@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        James Hogan <james.hogan@...tec.com>,
        James Morse <james.morse@....com>,
        Joseph Myers <joseph@...esourcery.com>,
        Lin Yongting <linyongting@...wei.com>,
        Manuel Montezelo <manuel.montezelo@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Martin Schwidefsky <schwidefsky@...ibm.com>,
        Maxim Kuvyrkov <maxim.kuvyrkov@...aro.org>,
        Nathan_Lynch <Nathan_Lynch@...tor.com>,
        Philipp Tomsich <philipp.tomsich@...obroma-systems.com>,
        Prasun Kapoor <Prasun.Kapoor@...iumnetworks.com>,
        Ramana Radhakrishnan <ramana.gcc@...glemail.com>,
        Steve Ellcey <sellcey@...iumnetworks.com>,
        Szabolcs Nagy <szabolcs.nagy@....com>
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)

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

Powered by blists - more mailing lists