[ML] Update seccomp filter for Fedora 29 #354
Conversation
Fedora 29 uses different system calls to platforms we've previously tested on, and hence suffers from certain functionality failing due to the seccomp filter. This commit permits 3 additional system calls: 1. __NR_gettimeofday 2. __NR_unlinkat 3. __NR_getdents64 (It is likely that other Linux distributions using modern glibc would also hit one or more of these system calls. Non-fatal problems probably got progressively worse in the lead up to the fatal problem that surfaced in Fedora 29.) Fixes elastic#350
|
There is an error in the existing code here That line checks the architecture is x64, the false branch of the jump eq statement should go to line 100 where the call is disallowed. I think the 5 should be changed to This is impossible to check as we don't build for any other architectures, TBH I'm struggling to remember why it is there in the first place as the code will not run on any other architectures. |
I think it should be 41 rather than 42, because we want to jump to disallow rather than allow. But maybe a better solution is to remove that check. Like you say, since the filter is being configured in native code that will only run on I can see that this check is useful in the Java seccomp code where the calls are being made via dynamic symbol lookups in the OS libraries using JNA, and the program could be running in a JVM on some other hardware architecture. But for native code that's already tied to a specific architecture it seems like a step too far. |
|
Ha I was right the first time there's a lesson about double checking there. The java seccomp does make that check but I followed the example on the seccomp BPF man page http://man7.org/linux/man-pages/man2/seccomp.2.html. Scroll down to the bottom and you'll see that I was guilty of some copy & paste. I now know where the
I agree, the check is redundant |
Since the filter is being installed by native code that will only work on one architecture, there is no need to check the architecture as part of the filter.
Fedora 29 uses different system calls to platforms we've previously tested on, and hence suffers from certain functionality failing due to the seccomp filter. This commit permits 3 additional system calls: 1. __NR_gettimeofday 2. __NR_unlinkat 3. __NR_getdents64 (It is likely that other Linux distributions using modern glibc would also hit one or more of these system calls. Non-fatal problems probably got progressively worse in the lead up to the fatal problem that surfaced in Fedora 29.) Fixes elastic#350 Backport of elastic#354
Fedora 29 uses different system calls to platforms we've previously tested on, and hence suffers from certain functionality failing due to the seccomp filter. This commit permits 3 additional system calls: 1. __NR_gettimeofday 2. __NR_unlinkat 3. __NR_getdents64 (It is likely that other Linux distributions using modern glibc would also hit one or more of these system calls. Non-fatal problems probably got progressively worse in the lead up to the fatal problem that surfaced in Fedora 29.) Fixes #350 Backport of #354
|
To be clear, the changes in this PR that allow the ML code to work on Fedora 29 are also required for any Linux distribution that uses glibc 2.28. Fedora 29 uses glibc 2.28: https://fedoraproject.org/wiki/Changes/GLIBC228#Summary The change in glibc 2.28 that results in the need for |
|
hi, could you please help me to solve these errors. |
|
@Hossein-b I think you need the changes from #1132. Hopefully that will be merged to master within a day or two. |
|
Thanks, it works. Now, I need your help on how to bind this code to Etasticsearch, thank you. |
@Hossein-b we are still working through this, so the easiest thing would probably be to wait a few weeks until we're finished. However, if you want to have a go yourself then this is what to do on your aarch64 machine:
I cannot promise this will work, as we are still developing it. Maybe there will be a silly one line typo that stops it working or maybe something harder to fix. |
|
Thank you @droberts195 for your kind help. Really I have a real aarch64 platform and I don't want to use Docker. Is there any config that I can change it to use real aarch64 platform? Here is the error that I got: |
|
@Hossein-b try building just the If it works your install bundle will be in |
|
Thanks, as you know Elasticsearch is written in java and it doesn't matter which platform you are using. My question is: is there any new release of Elasticsearch that ml-cpp is activated for aarch64 platform? in case I don't need to build an Elasticsearch form source. |
Not at present. There will be in the future - we are working on it. However, we cannot say exactly which version this will be. |
|
Hi David, is that means after activate a 1 munth trial version I can test machine-learning anomaly detection example? |
Yes, you should be able to use machine learning for one month on a trial license. Of course, you might find bugs specific to aarch64 because you will be the first person ever to try running an ML job on aarch64. Also, you won't be able to extend the trial as it's not a supported platform, so you have to realise that you're basically doing throwaway testing. If you are interested in running on aarch64 in the long term then it will probably be supported in a future version, but we cannot yet say when. |
Fedora 29 uses different system calls to platforms
we've previously tested on, and hence suffers from
certain functionality failing due to the seccomp
filter.
This commit permits 3 additional system calls:
(It is likely that other Linux distributions using
modern glibc would also hit one or more of these
system calls. Non-fatal problems probably got
progressively worse in the lead up to the fatal
problem that surfaced in Fedora 29.)
Fixes #350