<div dir="ltr">HI<div><br></div><div>Why/How will the user space tools switch over if the kernel does not support raw mode?</div><div>Isn't it a chicken&egg issue?</div><div><br></div><div>--Satish</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 4:13 PM, Richard Guy Briggs <span dir="ltr"><<a href="mailto:rgb@redhat.com" target="_blank">rgb@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 15/02/17, Viswanath, Logeswari P (MCOU OSTL) wrote:<br>
> I agree that changing the formatting of the records could break the existing applications<br>
> that consume them, and I didn't mean changing or eliminating of the formatting completely.<br>
> We agree that formatting is required for logging the records(as buffers) into the log files.<br>
> We are wondering if these records can be made available as RAW records so that the<br>
> analytical programs which are capable of reading them for processing can perform better.<br>
<br>
</span>There are tools that completely ignore any of the audit userspace suite<br>
including libaudit, so changing the formatting in the kernel and<br>
deferring to userspace to later do that formatting is not currently an<br>
option.<br>
<span class=""><br>
> This option of RAW mode for the events can be an additional option<br>
> where, kauditd delivers the audit buffer without formatting. Any<br>
> comments on this?<br>
<br>
</span>For a transition period if we were to consider it, it would mean<br>
rewriting *all* places in the kernel that generate audit messages and<br>
provide two paths switched on this RAW mode for each one of them, then<br>
copying all that duplication to userspace libaudit.<br>
According to Linus' decree, it would need to remain that way until we<br>
were certain that all tools including ones we don't know about had<br>
switched over.<br>
<span class="im HOEnZb"><br>
> >On Monday, February 16, 2015 11:25:57 AM Viswanath, Logeswari P wrote:<br>
> >> I configured the system to audit open system call alone instead of all<br>
> > >the system calls (our loader program executes) and hence I saw the<br>
> >> massive improvement in performance. My fix is not causing any change<br>
> > >in the performance. I wrongly communicated that the fix is causing<br>
> > >performance improvement. Sorry for that.<br>
> > ><br>
> >> As per the perf data, the format_decode is the function where most of<br>
> >> the time is spent i.e. formatting the record in the buffer before<br>
> > >delivering the data to user space. We need to eliminate formatting<br>
> > >records to increase the performance. Any idea why we need to format<br>
> > >the record and whether can we add an option (RAW) to deliver the<br>
> > >record without formatting to user space?<br>
><br>
> >Introducing any changes to the format of the record can cause all analytical programs, both open source and proprietary, to stop working correctly. This cannot be changed.<br>
> ><br>
> >I think there is room for improvement however. There are times when strings are being glued together and a stpcpy works just fine. There are times when a numeric hex conversion is being done and %x is very slow. Same with %d.<br>
> ><br>
> >The other issue is that the audit system's philosophy has not been to optimize the formatting of the event, because events _should_ be rare. Meaning that if you are getting hundred of events per second, something is seriously wrong with the rules.<br>
> ><br>
> >It has been optimized to provide as little impact as possible when _not_ generating events. Meaning that we want it as fast as possible in letting the system operate normally.<br>
> ><br>
> >Again, there is room for improvement in both cases of triggering and not triggering events. But the format of events can't really change without a lot of coordination. I have a test suite here:<br>
> ><br>
> ><a href="http://people.redhat.com/sgrubb/audit/ausearch-test-0.5.tar.gz" target="_blank">http://people.redhat.com/sgrubb/audit/ausearch-test-0.5.tar.gz</a><br>
> ><br>
> >That can check that events are searchable by the main audit utility. If changes cause that to fail, then its a sign you'll break the whole world.<br>
> ><br>
> >-Steve<br>
><br>
><br>
<br>
</span><span class="im HOEnZb">- RGB<br>
<br>
--<br>
Richard Guy Briggs <<a href="mailto:rbriggs@redhat.com">rbriggs@redhat.com</a>><br>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat<br>
Remote, Ottawa, Canada<br>
Voice: <a href="tel:%2B1.647.777.2635" value="+16477772635">+1.647.777.2635</a>, Internal: (81) 32635, Alt: <a href="tel:%2B1.613.693.0684x3545" value="+16136930684">+1.613.693.0684x3545</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">--<br>
Linux-audit mailing list<br>
<a href="mailto:Linux-audit@redhat.com">Linux-audit@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/linux-audit" target="_blank">https://www.redhat.com/mailman/listinfo/linux-audit</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Please Donate to <a href="http://www.wikipedia.org">www.wikipedia.org</a></div>
</div>