[PATCH v2] audit: report audit wait metric in audit status reply

[Paul Moore]

On Thu, Dec 3, 2020 at 7:37 AM Richard Guy Briggs <rgb at redhat.com> wrote:
> On 2020-12-02 23:12, Paul Moore wrote:
> > On Wed, Dec 2, 2020 at 10:52 PM Steve Grubb <sgrubb at redhat.com> wrote:
> > > We need this FEATURE_BITMAP to do anything in userspace. Max's instinct was
> > > right. Anything that changes the user space API needs to have a
> > > FEATURE_BITMAP so that user space can do the right thing. The lack of this is
> > > blocking acceptance of the pull request for the user space piece.
> >
> > I don't believe you need a new bitmap entry in this case, you should
> > be able to examine the size of the reply from the AUDIT_GET request
> > and make a determination from there.
>
> The danger I see is if another feature is added to the audit status and
> that is backported to a distro rather than this one.  It would be
> impossible to determine which feature it was from the size alone.
> Keying off specific fields in the kernel should be able to do
> this at build time if I understood correctly.

...

On Thu, Dec 3, 2020 at 8:31 AM Steve Grubb <sgrubb at redhat.com> wrote:
> For the upstream kernel, this may be the case. But in the world where people
> backport patches, how do I know that the size is related to this patch and no
> other?

We've discussed this in the past, and most of you should already know
my answer to this, but I'll repeat my stance on this again.

My first priority is the upstream kernel, enterprise distribution
kernels are secondary.  The upstream kernels do not generally backport
features, backports are limited to fixes.  If an individual or a
distribution decides to backport kernel features they are responsible
for making things work; it is not upstream's responsibility to enable,
or support, arbitrary combinations of patches.  Any assistance we
provide here is "best effort" and not guaranteed.

Bringing this back to the case at hand, the feature bitmap is a
limited resource and it is my opinion that we need to limit its use to
only those features which can not be determined through other means;
in this case this feature can be determine by the size of the
AUDIT_GET reply buffer (the audit_status struct).  Of course if more
care and thought had been put into the audit kernel/userspace API in
the first place we would not be in this situation, but we are and we
need to deal with it as best we can.

-- 
paul moore
www.paul-moore.com