linux-kernel - Re: [GIT PULL] lsm/lsm-pr-20240105

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]

Message-ID: <CAHC9VhRxG2jYayjpC=bLuBpfZsXnfYj_GoDBeK527sZWRe0ZrQ@mail.gmail.com>
Date: Wed, 10 Jan 2024 14:54:29 -0500
From: Paul Moore <paul@...l-moore.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] lsm/lsm-pr-20240105

On Tue, Jan 9, 2024 at 4:08 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, 5 Jan 2024 at 15:21, Paul Moore <paul@...l-moore.com> wrote:
> >
> >             The hightlights of the LSM pull
> > request are below, but before we get to that I want to mention that I
> > expect you will hit merge conflicts in the arch-specific syscall
> > tables as well as in the doc userspace-api documentation index.  Some
> > of these conflicts exist in your tree now (syscall tables), with some
> > others likely depending on what is submitted from linux-next and the
> > order in which you merge things.  All of the conflicts that I've seen
> > have been rather trivial and easily resolved, but I wanted to give you
> > a heads-up; if you want me to resolve any of these let me know.
>
> The tooling header file updates by the LSM tree were particularly annoying.
>
> Not because the conflicts were hard per se, but because you had done
> the header files wrong in the first place.
>
> Your version of the tooling header files just didn't match the real
> ones, as you had added your new system calls at the end mindlessly,
> without noticing that others had *not* done so, so all your tooling
> header system call number additions were just the wrong numbers
> entirely.
>
> I fixed it up, but it added an extra layer of "this is just annoying".
> You'd have been better off not touching the tooling headers at all,
> rather than touch them incorrectly.

Thanks for pulling the changes, I'm sorry the syscall table entries
for the LSM syscalls were not how you want to see them, but I'm more
than a little confused as to what exactly we did wrong here.  A more
detailed explanation would be helpful; if there is a doc somewhere
that explains the process, feel free to just drop a pointer.

I did provide a note in the pull request that based on linux-next
there were likely to be some conflicts in the syscall tables, but that
was evidently not sufficient, or we just added the syscall tables the
wrong way.  Your reply makes me believe we added the syscalls to the
arch tables the wrong way, but looking at your merge commit and the
files themselves (no helpful comments) I don't see anything obvious.
Quickly scanning the kernel docs doesn't reveal anything related
either, although I might be missing it.  The patches also didn't get
any comments regarding the syscall tables during review, and aside
from the numbering conflicts in linux-next, there were no comments
along the lines of "you need to do it this way" there either.

I want to do things The Right Way the next time around, but I need
some help to understand what that is ... ?

-- 
paul-moore.com