linux-kernel - Re: Audit fixes for v4.11 (#1)

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] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 26 Mar 2017 11:18:21 -0400
From:   Paul Moore <pmoore@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     linux-audit@...hat.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: Audit fixes for v4.11 (#1)

On Sat, Mar 25, 2017 at 6:23 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Mar 24, 2017 at 2:39 PM, Paul Moore <pmoore@...hat.com> wrote:
>>
>> This code has passed our testsuite without problem and it has held up
>> to my ad-hoc stress tests (arguably better than the existing code),
>> please consider pulling this as fix for the next v4.11-rcX tag.
>
> Ok, pulled. However, looking at the changes in the patch it becomes
> obvious that it is now completely bogus to inline the
> "audit_signal_info()" function.
>
> That silly inline in the header file now only generates bigger and
> slower code, since that inlined function now calls another function
> auditd_test_task() that is *not* inlined, so it ends up being a
> function call anyway.

Good catch.  I was so worried about the other issues in this patch I
missed this obvious point.

> It would be much better to just unlinline audit_signal_info(), move it
> into kernel/audit.c, and let the compiler then inline the
> __audit_signal_info() helper function (or just fold it into that
> function manually as part of the move).
>
> The whole reason for that inlined part, and the uninlined
> __audit_signal_info() helper was that the code *used* to be able to
> avoid a function call entirely. That reason is now gone.

Agreed.  Normally I would say let's just fix it in audit/next and I'll
send it to you during the next merge window; however, since we're
breaking the whole point of this inline in the -rcX stage, and the
uninline'ing patch would be rather trivial, would you prefer I send it
to you now for v4.11?

-- 
paul moore
security @ redhat