# 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)

- List: linux-api
- 4 messages, 3 authors
- Page: https://ratatoskr.run/linux-api/2021/07/1431636/t

## 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)

- From: Florian Weimer \<hidden\>
- Date: 2021-07-02 18:20:08 
- Message: https://ratatoskr.run/linux-api/2021/07/1431636.md

```text
* 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

```

## 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)

- From: Szabolcs Nagy \<hidden\>
- Date: 2021-07-05 09:37:56 
- Message: https://ratatoskr.run/linux-api/2021/07/1432927.md

```text
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)
```

## 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)

- From: Arnd Bergmann \<arnd@arndb.de\>
- Date: 2021-07-05 11:55:27 
- Message: https://ratatoskr.run/linux-api/2021/07/1433068.md

```text
On Mon, Jul 5, 2021 at 11:36 AM Szabolcs Nagy [ref] 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
```

## 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)

- From: Szabolcs Nagy \<hidden\>
- Date: 2021-07-05 12:10:22 
- Message: https://ratatoskr.run/linux-api/2021/07/1433082.md

```text
The 07/05/2021 13:55, Arnd Bergmann wrote:
> On Mon, Jul 5, 2021 at 11:36 AM Szabolcs Nagy [ref] 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.


```