linux-kernel - Re: [PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler flags for module objects

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: <Zry+sYwzCnZ94IwR@oracle.com>
Date: Wed, 14 Aug 2024 10:26:57 -0400
From: Kris Van Hees <kris.van.hees@...cle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Kris Van Hees <kris.van.hees@...cle.com>, linux-kernel@...r.kernel.org,
        linux-kbuild@...r.kernel.org, linux-modules@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org,
        Masahiro Yamada <masahiroy@...nel.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Jiri Olsa <olsajiri@...il.com>,
        Elena Zannoni <elena.zannoni@...cle.com>
Subject: Re: [PATCH v4 1/3] kbuild: add mod(name,file)_flags to assembler
 flags for module objects

On Fri, Jun 14, 2024 at 02:26:21PM -0400, Steven Rostedt wrote:
> On Fri, 14 Jun 2024 14:10:58 -0400
> Kris Van Hees <kris.van.hees@...cle.com> wrote:
> 
> > On Fri, Jun 14, 2024 at 01:46:51PM -0400, Steven Rostedt wrote:
> > > On Fri, 14 Jun 2024 13:14:26 -0400
> > > Kris Van Hees <kris.van.hees@...cle.com> wrote:
> > >   
> > > > Module objects compiled from C source can be identified by the presence
> > > > of -DKBUILD_MODFILE and -DKBUILD_MODNAME on their compile command lines.
> > > > However, module objects from assembler source do not have this defines.
> > > > 
> > > > Add $(modfile_flags) to modkern_aflags (similar to modkern_cflahs), and
> > > > add $(modname_flags) to a_flags (similar to c_flags).  
> > > 
> > > You explain what this does but not why it does it.  
> > 
> > The first paragraph is meant to estabish the "why" (being able to identify
> > what objects are module objects, even if they are compiled from assembler
> > source).
> 
> Perhaps there's a lack of context. Sure, the cover letter can help in
> this regard, but I always look at each commit as a stand alone.
> 
> > 
> > As I mention, for objects compiled from C source code, those defines being
> > present identifies those objects as belonging to a module.  For objects
> > compiled from assembler source code, those defines are not present.  Passing
> > them on the compile command line for assembler source code files for objects
> > that are part of one or more modules allows us to identify all objects that
> > are part of modules with a single consistent mechanism.
> 
> Sure, but why do we care? Again, if this was the only patch you sent,
> it should explain why it is being done.
> 
> Perhaps something like: "In order to be able to identify what code is
> from a module, even if it is built in, ..."
> 
> But what you are saying is just "C code has these flags, make
> assembly have them too". Which is meaningless.
> 
> The other patches could use some more explanation too.

Hi Steve,

Thank you for your feedback.  I hope that my new patch series [0] addresses
your questions.

Kris