3 ms·

It sounds like this wasn't the case in this instance, but applications could depend on kernel features without loading any kernel modules. The fact that they re

It sounds like this wasn't the case in this instance, but applications could depend on kernel features without loading any kernel modules. The fact that they required 3.10 is interesting because my first example would be user namespaces, which were completed around that point (I think they were mostly done by 3.8, but IIRC there were some significant features that weren't complete until 3.9-3.10). Edit - Here's some details about Chromium's dependency on these features: https://chromium.googlesource.com/chromium/src/+/lkcr/docs/linux_sandboxing.md https://chromium.googlesource.com/chromium/src/+/lkcr/docs/l...

pm215 9y ago
Yes. "We assume and rely on system call X being implemented" is another common case. In particular, glibc will check your kernel version and won't run if it is too old for what it was built against: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/dl-osinfo.h;h=823cd8224df939134018fbd8f0227e9f501393ab;hb=HEAD#l42 https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/uni... (Comments in that code notwithstanding, I think that the glibc configure will always define a minimum kernel version: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/configure.ac;h=13abda0a51484c5951ffc6d718aa36b72f3a9429;hb=HEAD#l36 https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/uni... and so the check always happens.)
- joshumax 9y ago
  The problem for me is that my kernel appeared to be too "new" for Nessus since they set minimum and maximum version ranges. Oddly enough it never impacted function AFAIK.