You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/usr/include/aarch64-linux-gnu/sys/syscall.h may seem more natural at first, but it appear that more recent versions of the Linux kernel have shifted where syscall information resides.
Another issue I ran into is that arm64 does not support the same syscalls as x86/x86-64, e.g. access, chmod, chown, etc are missing. So, for example, compiling with the access syscall fails:
In file included from /vagrant/src/module/linux/krf.c:112:
/vagrant/src/module/linux/krf.gen.x: In function ‘init_module’:
/vagrant/src/module/linux/krf.gen.x:6:21: error: ‘__NR_access’ undeclared (first use in this function); did you mean ‘mm_access’?
6 | krf_faultable_table[__NR_access] = (void *)&krf_sys_access;
| ^~~~~~~~~~~
| mm_access
/vagrant/src/module/linux/krf.gen.x:6:21: note: each undeclared identifier is reported only once for each function it appears in
In file included from /vagrant/src/module/linux/syscalls.c:10:
/vagrant/src/module/linux/syscalls.gen.x: In function ‘krf_sys_access’:
/vagrant/src/module/linux/syscalls.gen.x:15:80: error: ‘__NR_access’ undeclared (first use in this function)
15 | long (*real_access)(const struct pt_regs* regs) = (void *)krf_sys_call_table[__NR_access];
| ^~~~~~~~~~~
/vagrant/src/module/linux/syscalls.gen.x:15:80: note: each undeclared identifier is reported only once for each function it appears in
The codegen functionality tries to use every syscall with a corresponding .yml file, e.g. src/module/codegen/linux/access.yml. So compilation fails on arm64 when trying to compile against the access syscall. I wonder if there's an easy way to modify the codegen to only use syscall YAML files present for that architecture.
This is just the first blocker I've found regarding arm64 support, there may be more. For example, does the cr0 injection technique work on arm64, or do we need something else?
Anyway, I figured I would document what I've learned and open an issue request general support for arm64. This would make it easier to run krf on Apple silicon and other ARM systems.
The text was updated successfully, but these errors were encountered:
Thanks @mschwager! Another thing that an ARM port will need to do is replace/remove the current cr0 twiddling, since that's x86 only.
Thinking out loud: the simplest way to get the syscall templates working is probably to add an arch: <list> field to each, where the list specifies the set of uname arches that the syscall applies to. An empty list would imply only x86/AMD64, since that's the current default.
I've tried getting
krf
running on a Ubuntu 24.04 VM on Apple silicon (arm64), but ran into some issues.One issue is where to get the syscall definition information. It appears we'll need to make the following change to the codegen functionality:
/usr/include/aarch64-linux-gnu/sys/syscall.h
may seem more natural at first, but it appear that more recent versions of the Linux kernel have shifted where syscall information resides.Another issue I ran into is that arm64 does not support the same syscalls as x86/x86-64, e.g.
access
,chmod
,chown
, etc are missing. So, for example, compiling with theaccess
syscall fails:The codegen functionality tries to use every syscall with a corresponding
.yml
file, e.g.src/module/codegen/linux/access.yml
. So compilation fails on arm64 when trying to compile against theaccess
syscall. I wonder if there's an easy way to modify the codegen to only use syscall YAML files present for that architecture.This is just the first blocker I've found regarding arm64 support, there may be more. For example, does the
cr0
injection technique work on arm64, or do we need something else?Anyway, I figured I would document what I've learned and open an issue request general support for arm64. This would make it easier to run
krf
on Apple silicon and other ARM systems.The text was updated successfully, but these errors were encountered: