linux-kernel - Re: Exposing device ids and driver names

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: <4AC5003D.5020304@natemccallum.com>
Date:	Thu, 01 Oct 2009 15:17:17 -0400
From:	Nathaniel McCallum <nathaniel@...emccallum.com>
To:	Greg KH <greg@...ah.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Exposing device ids and driver names

On 10/01/2009 03:07 PM, Greg KH wrote:
> On Thu, Oct 01, 2009 at 02:56:55PM -0400, Nathaniel McCallum wrote:
>> On 10/01/2009 02:40 PM, Greg KH wrote:
>>> On Thu, Oct 01, 2009 at 02:35:40PM -0400, Nathaniel McCallum wrote:
>>>> On 10/01/2009 02:05 PM, Greg KH wrote:
>>>>> On Thu, Oct 01, 2009 at 01:01:50PM -0400, Nathaniel McCallum wrote:
>>>>>> On 10/01/2009 12:42 PM, Greg KH wrote:
>>>>>>> Why not just use the baseline kernel as a model for this.  Do a 'make
>>>>>>> allmodconfig' and then extract the data and publish it that way.  No
>>>>>>> kernel changes are needed, and then any distro can be easily matched up
>>>>>>> by this based on what they are using.  That will save you time in
>>>>>>> downloading zillions of distro releases, and provide a nice easy way to
>>>>>>> show what the kernel.org releases support.
>>>>>>
>>>>>> Unfortunately, I would not be able to track changes to the kernel in
>>>>>> this model.  Since this is one of my explicit goals (to make sure that
>>>>>> distro kernel changes get upstream), I think a non-invasive kernel
>>>>>> modification would be worth the effort.
>>>>>
>>>>> But this was an invasive modification, it added space to the kernel
>>>>> images for no real benifit other than for your tracking tools.  That's
>>>>> not going to fly unless you can find another good use for the change.
>>>>
>>>> Which is why I asked for advice for better options.  I would prefer a
>>>> non-invasive modification.  I am hoping that someone more familiar with
>>>> the layer would provide such a suggestion.
>>>>
>>>> One potential benefit for moving module info to ELF sections would be
>>>> the ability to strip kernel modules.  As a test, I did this on a recent
>>>> Fedora rawhide kernel I had lying around.  Stripping the modules results
>>>> in a 43% decrease in size (82M to 47M).
>>>
>>> Did those modules have debugging symbols enabled?  That seems like a
>>> large savings for just the module device tables.
>>
>> It does not appear so (none of the debug sections are present).  But I
>> could be wrong.
>>
>> Stripping the modules on the penultimate Fedora 11 kernel results in the
>> same drop in size.  I can't imagine why a release kernel would have
>> anything extra left in the modules (unless it is just by accident).
>
> Are you sure things still work after stripping?  Stuff like systemtap
> and other tools?

Not at all.  I have no idea what the ramifications are.

My point was merely that whatever is stripped out of the kernel should 
be able (in theory) to be stripped from the modules.  The only point of 
difference should be the actual module symbols themselves which can in 
stead be stored in ELF sections.

Nathaniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/