Re: [RFC PATCH 3/3] kallsyms: add option to include relative filepaths into kallsyms

[Greg KH]

On Fri, Aug 19, 2022 at 05:00:24PM +0200, Alexander Lobakin wrote:
> From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> Date: Fri, 19 Aug 2022 13:02:55 +0200
> 
> > On Fri, Aug 19, 2022 at 12:50:01PM +0200, Alexander Lobakin wrote:
> > > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > Date: Thu, 18 Aug 2022 16:11:10 +0200
> > > 
> > > > On Thu, Aug 18, 2022 at 03:56:29PM +0200, Alexander Lobakin wrote:
> > > > > From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > > > Date: Thu, 18 Aug 2022 14:23:43 +0200
> > > > > 
> > > > > > On Thu, Aug 18, 2022 at 01:53:06PM +0200, Alexander Lobakin wrote:
> > > > > > > Currently, kallsyms kernel code copes with symbols with the same
> > > > > > > name by indexing them according to their position in vmlinux and
> > > > > > > requiring to provide an index of the desired symbol. This is not
> > > > > > > really quite reliable and is fragile to any features performing
> > > > > > > symbol or section manipulations such as FG-KASLR.
> > > > > > 
> > > > > > Ah, here's the reasoning, stuff like this should go into the 0/X message
> > > > > > too, right?
> > > > > > 
> > > > > > Anyway, what is currently broken that requires this?  What will this
> > > > > > make easier in the future?  What in the future will depend on this?
> > > > > 
> > > > > 2) FG-KASLR will depend and probably some more crazy hardening
> > > > >    stuff. And/or perf-based function/symbol placement, which is
> > > > >    in the "discuss and dream sometimes" stage.
> > > > 
> > > > I have no idea what "FG-KASLR" is.  Why not submit these changes when
> > > > whatever that is is ready for submission?
> > > 
> > > It doesn't matter much, the main idea is that the current approach
> > > with relying on symbol positions in the vmlinux is broken when we
> > > reorder symbols during the kernel initialization.
> > > As I said, this is an early RFC do discuss the idea and the
> > > implementation. I could submit it along with FG-KASLR, but then if
> > > there would be major change requests, I'd need to redo lots of
> > > stuff, which is not very efficient. It's better to settle down the
> > > implementation details in advance.
> > 
> > It's better for you to get this all working on your own first, before
> > asking the community to review and accept something that is not required
> > at all for the kernel today.  Why waste our time for no benefit to the
> > kernel now?
> 
> I didn't ask anyone to waste his time or review or accept (BTW,
> accept RFC?). Who is interested, can take a look and do whatever
> he wants.
> 
> I thought RFCs work that way... I remember one guy came to the
> netdev several months with an idea. He also had early RFC which was
> submitted only to show the direction of thought, many parts were
> missing as they required establishing the design.
> So there was a discussion with advices and no objections. After it
> calmed cown, he went back to finish stuff and a week ago he came
> with a "regular" version already, with all the stuff finished and
> all the drivers converted (100+).
> Would it be better if he didn't do an early RFC, finished all the
> stuff first, then published v1, then someone told him "no, do it
> the other way around" and he went back to redo 100+ drivers
> conversion?
> Confused =\

I'll let you work out the issues with how Intel is supposed to be
submitting patches to the kernel with your internal management chain, as
there are some restrictions that you all have that other (i.e. everyone
else) do not have.

good luck!

greg k-h