lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1593449858.5085.24.camel@linux.ibm.com>
Date:   Mon, 29 Jun 2020 12:57:38 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Paul Moore <paul@...l-moore.com>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>
Cc:     sgrubb@...hat.com, rgb@...hat.com, linux-integrity@...r.kernel.org,
        linux-audit@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] IMA: Add audit log for failure conditions

On Thu, 2020-06-25 at 15:14 -0400, Paul Moore wrote:
> On Wed, Jun 24, 2020 at 1:25 PM Lakshmi Ramasubramanian
> <nramas@...ux.microsoft.com> wrote:
> >
> > On 6/23/20 12:58 PM, Mimi Zohar wrote:
> >
> > Hi Steve\Paul,
> >
> > >> Sample audit messages:
> > >>
> > >> [    6.303048] audit: type=1804 audit(1592506281.627:2): pid=1 uid=0
> > >> auid=4294967295 ses=4294967295 subj=kernel op=measuring_key
> > >> cause=ENOMEM comm="swapper/0" name=".builtin_trusted_keys" res=0
> > >> errno=-12
> > >
> > > My only concern is that auditing -ENOMEM will put additional memory
> > > pressure on the system.  I'm not sure if this is a concern and, if so,
> > > how it should be handled.
> >
> > Do you have any concerns with respect to adding audit messages in low
> > memory conditions?
> 
> Assuming the system is not completely toast, the allocation failure
> could be a very transient issue; I wouldn't worry too much about it.

There was a major clean up of removing ENOMEM error messages through
out the kernel a while ago by Wolfram Sang.  The subject lines
included "don't print error when allocating XXX fails".  As it turns
out, they were being removed because "kmalloc will print enough
information in case of failure."  It had nothing to do with memory
pressure on the system.

Thanks, Paul.  I think we're good.

Mimi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ