https://github.com/osquery/osquery logo
Join Slack
Powered by
Hi everyone, this is just an heads up. I believe `...
# core
a
Hi everyone, this is just an heads up. I believe 
osquery::InternalRunnable
(as other places probably) is affected by clock adjustments (for sure on Windows, not sure on other platforms). Found this bug that basically say 
std::this_thread::sleep_until
and 
std::this_thread::sleep_for
implementation are based on a 
system_clock
rather than a 
steady_clock
. On top of it possibly other functions are affected such as:
Copy code
std::condition_variable::wait_for
std::condition_variable::wait_until
std::condition_variable_any::wait_for
std::condition_variable_any::wait_until
std::future::wait_for
std::future::wait_until
std::recursive_timed_mutex::try_lock_for
std::recursive_timed_mutex::try_lock_until
std::shared_future::wait_for
std::shared_future::wait_until
std::shared_lock::try_lock_for
std::shared_lock::try_lock_until
std::shared_timed_mutex::try_lock_for
std::shared_timed_mutex::try_lock_until
std::shared_timed_mutex::try_lock_shared_for
std::shared_timed_mutex::try_lock_shared_until
std::timed_mutex::try_lock_for
std::timed_mutex::try_lock_until
std::unique_lock::try_lock_for
std::unique_lock::try_lock_until
shocked
s
What does this mean? Something like clock adjustments me throw off some of the internal concepts like “run this every hour”? Any idea how to fix it?
a
yeah exactly. Update on this is : for Windows apparently the 
condition_variable::wait_for
is not affected. But it is on Linux. The issue on linux seems like caused by glibc version 2.2.5. Version 2.3.0 fixes this issue.. So there is no complete fix in the short term.
s
I don't think we use the 
_until
variants, and CentOS 6 which was the oldest linux we supported, was using glibc 2.12
a
@Stefano Bonicatti is there any thought of upgrading the toolchain any soon ?
s
If this is related to the glibc issue, we've established that the issue is already solved because CentOS 6 (or 7 now) definitely has a newer glibc. Secondly, the glibc version being used is actually connected to the system osquery runs on, so it's not really a toolchain issue. But in general I would like to, but it takes quite some time because we have to reconfigure all the third party libraries (for x86_64 and aarch64), and then there are also the BPF libraries to update, because LLVM made changes to the APIs.
"the glibc version being used is actually connected to the system osquery runs on", more specifically, osquery always targets the version of the glibc functions that are present on the oldest reference distro (CentOS 7, although in practice right now is still CentOS 6). But then that's only what gets called as an interface, the actual implementation of those functions is the one provided by the glibc on the system. So if there's a bug and fixing it doesn't affect the glibc function ABI, the distro you're running osquery on could already have fixed the bug.
👍 1
5 Views
Open in Slack
PreviousNext
Powered by