ARM64: compat syscalls IDs might not be correct.

[AlonZivony]

Description

Introduction

Each syscall event has its 32bit ID, to translate the 32bit syscall ID to the matching event. The connection is based on which internal function handles the 32bit syscall.

Most of the times, 32bit syscalls are handled by the same handler as their 64bit version. For example, the openat event is registered for the openat 32bit syscall ID.

However, some syscalls are changed between 32bit to 64bit, so we had to make the matching manually.

For example, the select 32bit syscall ID is registered under the old_select event, while the select event is registered for the new_select 32bit syscall ID.

The Possible Problem

The manual matching, we did was based on the x86 syscall table.

If an ARM system was running in compatible 32bit mode, some syscalls might be registered under the wrong event.

For example, the select 32bit syscall might be handled by the select 64bit syscall handler, so it should be translated to select event instead of old_select.

This is just a speculation, but it is worth considering.

[AlonZivony]

@rafaeldtinoco can you share your opinion on this problem?

[yanivagman]

The ID32Bit constants are defined in a per-architecture file so we can simply define sys32select and sys32_newselect with the correct values in the ARM64 file, can't we?

[AlonZivony]

I gave them as an idea, as I am not really sure if the problem I suggest here really happens. I think someone needs to check that all the connections we made between the 64bit syscalls to the 32bit syscalls are accurate. There also might be syscalls which don't exist in x86, but I really don't know enough to tell if it is really possible or not.