Compatibility with kernels >= 5.7 #76
Conversation
On kernel 5.7 and later, kallsyms_lookup_name() can no longer be called from a kernel module for reasons described here: https://lwn.net/Articles/813350/ As binder really needs to use kallsysms_lookup_name() to access some kernel functions that otherwise wouldn't be accessible, KProbes are used on later kernels to get the address of kallsysms_lookup_name(). The function is afterwards used just as before. This is a very dirty hack though and the much better solution would be if all the functions that are currently resolved with kallsysms_lookup_name() would get an EXPORT_SYMBOL() annotation to make them directly accessible to kernel modules.
With the commit 64fe66e8a95e in the Linux kernel, the member "mmap_sem" in the struct mm_struct was renamed to "mmap_lock". This patch fixes the resulting compile errors.
With kernel 5.8, the return value of map_kernel_range_noflush() was changed. This function now returns 0 on success (instead of the number of successfully mapped pages). This commit adjusts binder accordingly.
|
This seems to work nicely on Fedora 33 with kernel 5.10. However, on Fedora 34 pre-release with kernel 5.11, it doesn't seem like the modules can be built at all. I am not sure if this is an issue with kernel 5.11 or if it is simply because Fedora 34 pre-release is still somewhat buggy, but it would be awesome if you can have a look :) |
|
Oh, and to add a bit more info, dkms was complaining about incompatible gcc/plugin versions when I tried it. |
|
Hello @TommyTran732 , unfortunately, I cannot invest the time to install Fedora 34 on my machine to duplicate this error... The only kind of help I can offer is to take a look at the error and see if something comes to my mind.. But for this I need the full console output. Best regards, Christian |
|
Hi, Fedora 33 just got updated to kernel 5.11 today and it seems like it broke binder. It is a different error from what I got on Fedora 34 last time, but here are the logs: `[Tomster@dhcp-172-30-79-244 ~]$ sudo ls -la /dev/{ashmem,binder} Kernel preparation unnecessary for this kernel. Skipping... Building module: |
|
Hello @TommyTran732 , yes, indeed it seems like some kernel changes broke the build. Unfortunately, I am travelling tomorrow and will be away for the next 3 weeks. Today I need to pack my things and it is unlikely that I find the time to look into it. I will try to have a look after I return. Best regards, Christian |
|
Is there any update on this? I'm too facing the same issue |
|
Hello @vikashraghavan , no, no update on this. And I don't know when / if I will look into it at all because kernel 5.11 is not yet available for Raspsberry Pi OS. If you have the skills (or someone else who is affected), you could try to fix it yourself and set a PR to my branch, which I will be happy to integrate. I cannot give any commitment if I find time for it at all. Best regards, Christian |
|
Hi @chrihoff I found some patch docs related to the error __alloc_fd I'm not sure whether it would be useful or not. |
|
Hello @vikashraghavan , I just had a look at these kernel patches. The links are helpful indeed and pointed me in the right direction. So, it seems like the functions __alloc_fd(), __fd_install() and __close_fd() were removed from the kernel without replacement. However, Binder was refactored upstream upstream in 2018 (see http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/125424.html). Since that refactoring, binder no longer needs to use these three functions and can use standard functions instead. So the task here would be to backport this refactoring to binder also to anbox-modules. That should fix those issues. Unfortunately, this refactoring is quite complex and involves some restructuring, so I am not sure how easy it would be to backport it. Then the only problem remaining would be the compile error in 'binder_mmap' that @TommyTran732 reported. As of now, I cannot tell what the root cause of this other error is or how to fix it as I simply didn't have the time to look into it. Best regards, Christian |
|
Hello @vikashraghavan , well, you could try to replace binder.c in anbox-modules by the latest one you found... Maybe you'd need to copy over other files, too... But this is not a generic solution for every user as anbox-modules were designed to be compilable against old kernels also. So, there is a lot of compatibility code in there that is missing in the version of binder.c for the latest kernel. Best regards, Christian |
|
Can you please mention which are the other files to be copied? |
|
Hello @vikashraghavan , unfortunately, I cannot tell and I don't have time to look into it, either. I guess you'd need to try yourself. I am not sure how well this approach works at all... Best regards, Christian |
|
Stuck over here while trying to compile latest binder module DKMS make.log for anbox-binder-1 for kernel 5.11.18-300.fc34.x86_64 (x86_64) Is there some changes should be done to deps.c? Any suggestions to direct me in the right way would be really helpful !!! |
Over the last years, many fixes and changes have been applied to Binder in the Linux kernel, but these fixes were never backported to anbox-modules. The meant that the version of Binder in anbox-modules was very outdated. With this commit, Binder has been update to the latest state from the Linux kernel. This should also fix the compile on kernel 5.12 and later.
|
hi, |
Linux 5.15.2 updated security.h security_binder_* functions (like security_binder_transfer_binder(), so it uses struct cred* instead of struct task_struct*)
|
Any chance to look at @Catiks problem ? I had the exactly same issue on ubuntu 21.10. Maybe something related to https://patchwork.kernel.org/project/linux-nfs/patch/[email protected]/ ? |
|
Hello @enz0nun3s15 and @Catiks , to me it looks like you are trying to compile anbox-modules even though binder and ashmem are already compiled with your kernel. But anbox-modules are intended only for the corner case that the kernel of your distribution doesn't include binder and ashmem already. Ubuntu 21.10 and also earlier versions include binder and ashmem in their kernel image, so no need to use anbox-modules. Best regards, Christian |
|
Actually I was trying to install it in a server with ubuntu server with custom kernel which hasn't the binder installed - there is no /lib/modules/5.13.0-22-X/kernel/drivers/android/ (I tried both Azure and Oracle). Any idea of how to handle it ? |
|
Hello @enz0nun3s15 , binder and ashmem are not compiled as kernel modules anymore. Instead, they are built into the main kernel (vmlinux). Therefore, you cannot find binder and ashmem under drivers/android. The only way to check if you kernel has binder and ashmem is to check the kernel config. I suppose that is the case, both because of the error message you see when compiling anbox-modules and then also because you are running Ubuntu (where the default kernel comes with binder and ashmem). Best regards, Christian |
If you are trying to use anbox try this anbox command: output should be printing something like this: best regards SI |
|
Some basic information to kernel building and installation:
|
|
@datsoy i rewrote my script for you. ❤️🔥 Please have a look at: How to use it:
The source code will be pulled with apt source from the ubuntu repository with the oracle branch… |
|
Hi, thanks for the updates. Currently i am running debian on a surface The output of the command is: The output of make.log: |
|
Hello Rick,
yes, for kernel 5.19 there is currently an open pull request, which I
first have to review and then merge into my branch:
choff#4 . Feel free to try it out
and let me know the result.
Best regards,
Christian
Message ID: ***@***.***
|
|
Hey, just tried the fork, can confirm it works |
|
Thanks! I can also confirm that for kernel 5.19 the pull request choff#4 works. |
|
@choff Is this PR up-to-date? Happy to merge it |
|
Hello @morphis , yes, the PR is up to date. After my original fixes (which fixed the compilation for kernel versions up to 5.13), I also received fixes for version 5.15 and 5.19 by the community (thank you all!). They are part of this PR, too. Best regards, Christian |
|
Hello @morphis, one last thing. I think this PR will break compilation with old kernels (older than v5.12 or v5.11). The reason for this is that I updated the code for binder inside anbox-modules to the upstream state of binder from kernel 5.12 or 5.11 (cannot exactly remember which version I used). The main reason for this update of the binder inside anbox-modules was that the binder code shipped with anbox-modules was outdated. The upstream version of binder has received many fixes meanwhile. Also, the function signature of many functions used by binder changed in newer kernel versions and I remember that it was very hard to backport these changes to the outdated binder code in anbox-modules. This is why I decided to update binder. There is also an "old-kernel" branch in my GIIT repo that works (only) with older kernels up to 5.11. On that branch, I did not update the code of binder. Best regards, Christian |
|
Hi @choff, FYI: this is a possible fix for kernel 6.0 based on this request. It compiles, but is currently untested: |
See torvalds/linux@f5d39b0 for more info.
See also: torvalds/linux@278832b This results to a build failure on 6.6 kernel without this commit.
* Use shrinker pointer instead of shrink struct for 6.7+, due to the `shrinker_alloc` function always return the pointer. * Most of the codes are stolen from drivers/android/binder_alloc.c
* removed obsolete name="%k", added binder symlink * removed obsolete name="%k", added binder symlink
Added packaging guide and compat fix
…nder anbox-vndbinder
Various changes were made to get the kernel modules for Anbox working with kernels 5.7 and later:
I know that ashmem and binder are now upstream in the kernel, but there are still many distributions that don't enable ashmem and binder support in their kernel config. In that case, one might still want to try "anbox-modules" if nothing else helps. This patch makes it possible to compile ashmem and binder as kernel modules with such newer kernels. It's surely not a great solution, but it's a solution of last resort.