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]
Date:   Tue, 17 Jan 2017 08:29:15 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Eric Paris <eparis@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-audit@...hat.com,
        Steve@...hat.com
Subject: Re: [PATCH V2] audit: log 32-bit socketcalls

On Mon, Jan 16, 2017 at 10:53 PM, Richard Guy Briggs <rgb@...hat.com> wrote:
> On 2017-01-16 15:04, Paul Moore wrote:
>> On Fri, Jan 13, 2017 at 9:42 AM, Eric Paris <eparis@...hat.com> wrote:
>> > On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
>> >> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> >> index 9d4443f..43d8003 100644
>> >> --- a/include/linux/audit.h
>> >> +++ b/include/linux/audit.h
>> >> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
>> >> unsigned long *args)
>> >>               return __audit_socketcall(nargs, args);
>> >>       return 0;
>> >>  }
>> >> +static inline int audit_socketcall_compat(int nargs, u32 *args)
>> >> +{
>> >> +     if (unlikely(!audit_dummy_context())) {
>> >
>> > I've always hated these likely/unlikely. Mostly because I think they
>> > are so often wrong. I believe this says that you compiled audit in but
>> > you expect it to be explicitly disabled. While that is (recently) true
>> > in Fedora I highly doubt that's true on the vast majority of systems
>> > that have audit compiled in.
>>
>> Richard and I have talked about the likely/unlikely optimization
>> before and I know Richard likes to use them, but I don't for the
>> reasons Eric has already mentioned.   Richard, since you're respinning
>> the patch, go ahead and yank out the unlikely() call.
>
> I don't "like to use them".  I'm simply following the use and style of
> existing code and the arguments of others in places of critical
> performance.

Okay that's a reasonable reason for why you continued the tradition,
however I'm asking you (for the second time now) not to use it in
audit_socketcall_compat().

> If I "fix" that one, then I would feel compelled to yank
> out the one in the function immediately above, audit_socketcall() for
> consistency to ease my conscience.  Eric conceded that argument.

I'll be very clear on what I want to see in this patch: don't use
likely/unlikely in audit_socketcall_compat() and don't touch it's use
in the other functions at this point in time.

-- 
paul moore
www.paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ