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
* Yury Norov:
> 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?
I believe that glibc has the infrastructure now to integrate an ILP32
port fairly cleanly, although given that it would be first
post-libpthread work, it would have to absorb some of the cleanup work
for such a configuration.
(I do not plan to work on this myself.)
Thanks,
Florian
The 07/02/2021 20:19, Florian Weimer wrote:
> * Yury Norov:
> > 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?
>
> I believe that glibc has the infrastructure now to integrate an ILP32
> port fairly cleanly, although given that it would be first
> post-libpthread work, it would have to absorb some of the cleanup work
> for such a configuration.
time64 would require syscall abi design changes.
(that's likely an abi break compared to what the
listed users do)
On Jul 02 2021, Yury Norov wrote:
> At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer
> actively use and develop arm64/ilp32.
This is good to know. Where can I get the uptodate kernel patches for
ILP32?
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Mon, Jul 5, 2021 at 11:36 AM Szabolcs Nagy <[email protected]> wrote:
> The 07/02/2021 20:19, Florian Weimer wrote:
> > * Yury Norov:
> > > 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?
> >
> > I believe that glibc has the infrastructure now to integrate an ILP32
> > port fairly cleanly, although given that it would be first
> > post-libpthread work, it would have to absorb some of the cleanup work
> > for such a configuration.
>
> time64 would require syscall abi design changes.
> (that's likely an abi break compared to what the
> listed users do)
The kernel port uses the generic syscall ABI, and has done so from the start,
so both time32 and time64 syscalls are supported in principle, as they are
on any other 32-bit architecture these days (except rv32, which dropped
the time32 variant, and x32, which uses the time64 calling conventions but
the time32 syscall names).
Arnd
The 07/05/2021 13:55, Arnd Bergmann wrote:
> On Mon, Jul 5, 2021 at 11:36 AM Szabolcs Nagy <[email protected]> wrote:
> > The 07/02/2021 20:19, Florian Weimer wrote:
> > > * Yury Norov:
> > > > 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?
> > >
> > > I believe that glibc has the infrastructure now to integrate an ILP32
> > > port fairly cleanly, although given that it would be first
> > > post-libpthread work, it would have to absorb some of the cleanup work
> > > for such a configuration.
> >
> > time64 would require syscall abi design changes.
> > (that's likely an abi break compared to what the
> > listed users do)
>
> The kernel port uses the generic syscall ABI, and has done so from the start,
> so both time32 and time64 syscalls are supported in principle, as they are
> on any other 32-bit architecture these days (except rv32, which dropped
> the time32 variant, and x32, which uses the time64 calling conventions but
> the time32 syscall names).
i haven't seen the updated ilp32 patches on top of
the time64 work: the glibc side only uses time32 on
ilp32 currently, but adding a new 32bit port now to
glibc requires 64bit time_t which means some things
would have to be done differently.
the glibc changes would likely not be compatible
with whatever the current ilp32 users do and on
the kernel side it would be better to only expose
time64 like on rv32, which is a syscall abi change.
On Fri, Jul 2, 2021 at 8:07 PM Yury Norov <[email protected]> wrote:
> On Thu, Jul 01, 2021 at 05:08:45AM -0700, Paul Moore wrote:
>
> 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.
I think the overall tradeoff is not that different from what it was in the
past. Keeping it out of the tree clearly creates extra work both for you
and the users, but reduces the overhead for everyone else, who
can ignore that corner case. We have tried removing both x86-x32
support and arm64 big-endian support from the kernel not that long
ago. Both have considerably more impact on kernel maintenance than
your aarch64-ilp32 work, and they probably even have fewer users,
but we always ended up keeping the status quo.
However, there are clearly some changes that happened over the
past few years that may be relevant here:
- The expectation in the past was that ilp32 support would eventually
go away as users move on to full 64-bit support. It has survived a
lot longer than I would have guessed, but I still find it hard to tell
whether this would continue. What's more important than the current
number of users is how many of those you expect to run linux-6.x
or linux-7.x with aarch64-ilp32 in the future.
- Another thing that has changed is that we now have a rough timeline
for aarch32 support to be removed from future Arm processors. If
no Armv9 processors after 2022 support Aarch32 mode, we may see
interest in ilp32 mode go up between 2025 and 2030 when those
processors make it into more markets.
- On the other hand, interest in not just 32-bit hardware running Linux
but also in 32-bit user space is already declining overall. We'll
probably still see some 10 to 20 years of 32-bit user space
deployments on (mostly) memory constrained systems, but this
is getting increasingly obscure as more applications run into
virtual memory space restrictions (3GB or 4GB typically) before
they exceed the available RAM. On RV64 and ARCv3, there is
already a conclusion that they will not support 32-bit user space,
neither ilp32 style on 64-bit instructions nor with hardware support
for RV32/ARC32 binaries. I expect the same for Loongarch.
Arnd
On Mon, Jul 05, 2021 at 12:48:42PM +0200, Andreas Schwab wrote:
> On Jul 02 2021, Yury Norov wrote:
>
> > At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer
> > actively use and develop arm64/ilp32.
>
> This is good to know. Where can I get the uptodate kernel patches for
> ILP32?
>
> Andreas.
The latest kernel supported by me is 5.2:
https://github.com/norov/linux/commits/ilp32-5.2
I know about working ports of ILP32 on 5.7 and 5.10, but didn't see
the code and testing results. Hopefully Paul Moore and Weiyuchen will
share more details.
Yury
On Wed, Jul 7, 2021 at 2:44 PM Yury Norov <[email protected]> wrote:
> On Mon, Jul 05, 2021 at 12:48:42PM +0200, Andreas Schwab wrote:
> > On Jul 02 2021, Yury Norov wrote:
> >
> > > At least Marvell, Samsung, Huawei, Cisco and Weiyuchen's employer
> > > actively use and develop arm64/ilp32.
> >
> > This is good to know. Where can I get the uptodate kernel patches for
> > ILP32?
> >
> > Andreas.
>
> The latest kernel supported by me is 5.2:
> https://github.com/norov/linux/commits/ilp32-5.2
>
> I know about working ports of ILP32 on 5.7 and 5.10, but didn't see
> the code and testing results. Hopefully Paul Moore and Weiyuchen will
> share more details.
To be clear, I have not done any work with ILP32 nor do I have any
immediate plans to do so (other tasks are higher priority). I am not
sure what details you are looking for, but there are several
arches/ABIs in the kernel, including regular aarch64, that can serve
as examples on how to enable syscall auditing (presumably that is what
you are interested in with this thread). There may be some
interesting challenges with ILP32 due to overlap with aarch64
syscalls, but I haven't looked closely enough at ILP32 to say that
with any certainty.
--
paul moore
http://www.paul-moore.com