On Tue, Jun 16, 2020 at 12:58 AM Max Englander <max.englander(a)gmail.com> wrote:
 In environments where security is prioritized, users may set
 --backlog_wait_time to a high value in order to reduce the likelihood
 that any audit event is lost, even though doing so may result in
 unpredictable performance if the kernel schedules a timeout when the
 backlog limit is exceeded. For these users, the next best thing to
 predictable performance is the ability to quickly detect and react to
 degraded performance. This patch proposes to aid the detection of kernel
 audit subsystem pauses through the following changes:
 Add a variable named audit_backlog_warn_time. Enforce the value of this
 variable to be no less than zero, and no more than the value of
 audit_backlog_wait_time.
 If audit_backlog_warn_time is greater than zero and if the total time
 spent waiting to enqueue an audit record is greater than or equal to
 audit_backlog_warn_time, then print a warning with the total time
 spent waiting.
 An example configuration:
         auditctl --backlog_warn_time 50
 An example warning message:
         audit: sleep_time=52 >= audit_backlog_warn_time=50
 Tested on Ubuntu 18.04.04 using complementary changes to the audit
 userspace: 
https://github.com/linux-audit/audit-userspace/pull/131.
 Signed-off-by: Max Englander <max.englander(a)gmail.com>
 ---
  include/uapi/linux/audit.h |  7 ++++++-
  kernel/audit.c             | 35 +++++++++++++++++++++++++++++++++++
  2 files changed, 41 insertions(+), 1 deletion(-) 
If an admin is prioritizing security, aka don't loose any audit
records, and there is a concern over variable system latency due to an
audit queue backlog, why not simply disable the backlog limit?
-- 
paul moore
www.paul-moore.com