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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3de91507-37e8-d231-8595-d04c8ae8f448@infradead.org>
Date:   Wed, 29 Nov 2017 19:19:55 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Lee Strobel <leestrobel@...root.org>
Cc:     linux-kernel@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Missing version line in System.map file?

On 11/29/2017 06:56 PM, Lee Strobel wrote:
> Hi Randy,
> 
> Thank you for replying to my e-mail. That is interesting and it seems to
> explain why my map file didn't have that version line. I hadn't realized
> that it depends on the CONFIG_KALLSYMS option (which I did indeed have
> enabled). I am somewhat new to configuring/building the kernel and, from
> the help description, enabling that option seemed like a good idea at
> the time.

Yes, I agree.

> However, I think it would be good if the map file could be set to always
> include the version line, if that would help compatibility with sysklogd
> (and, of course, if it doesn't break anything else).
> 
> So, is that an easy change to make? How will I know if it gets approved
> for the next version release?

It's easy to make the change on my system.
It's not so easy to know if that change would be approved (merged).

What does not having that line in the System.map file break?
Should klogd be looking in the System.map file for a kernel version number?
Can you make a good argument for this change?

OTOH, all it does is add an integer variable to the kernel and one line to
the System.map file, so if it fixes something, it shouldn't be a big deal.

> Also, can you tell me which kernel version that previous change was made
> in?

Probably 2.6.27.

> Sorry for all the questions, but I haven't had any previous involvement
> with kernel development.

No problem.

> Regards,
> 
> Lee
> 
> 
> On Wed, 2017-11-29 at 11:31 -0800, Randy Dunlap wrote:
>> On 11/29/2017 11:07 AM, Randy Dunlap wrote:
>>> On 11/28/2017 07:20 PM, Lee Strobel wrote:
>>>> Hi,
>>>>
>>>> I have a question about the Linux kernel, which I have been trying to
>>>> find an answer to through various forums for some time now, but without
>>>> success. I'm wondering if anyone on this mailing list might be able to
>>>> help?
>>>>
>>>> I've been trying to build a Linux From Scratch (LFS) system, using
>>>> SysVinit and sysklogd. However, when I tried to boot up, klogd wasn't
>>>> accepting the System.map file, printing log messages such as:
>>>>
>>>>    Oct 9 17:24:17 <lee_lfs> kernel: klogd 1.5.1, log source = /proc/kmsg
>>>> started.
>>>>    Oct 9 17:24:17 <lee_lfs> kernel: Inspecting /boot/System.map
>>>>    Oct 9 17:24:17 <lee_lfs> kernel: Cannot find map file.
>>>>
>>>> So, I dug into the source code for klogd a little bit, and it appears
>>>> the reason the map file wasn't being accepted was because it didn't
>>>> contain a 'version' line, which klogd was looking for, in the form:
>>>>
>>>>    [address] [type] Version_XXXXX
>>>>
>>>> (where XXXXX is the kernel version # in base 256).
>>>>
>>>> So, I've been asking around on various forums. It seems that none of the
>>>> map files that are being produced by more recent kernel versions include
>>>> this line and no-one that I've spoken to on the Linux user forums seems
>>>> to know why this is.
>>>>
>>>> Was a change made to the kernel, to remove this 'version' line
>>>> from the map file? If so, how are the newer init systems verifying that
>>>> the map file is the same version as the running kernel? Perhaps sysklogd
>>>> needs to be updated?
>>>>
>>>> By the way, I tried adding a 'dummy' version line to my map file and
>>>> klogd accepted it fine.
>>>>
>>>> Hopefully someone out there can assist, as no-one in the Linux user
>>>> community seems to know what is going on with this.
>>>>
>>>> Best regards,
>>>>
>>>> Lee Strobel
>>>> Engineer/Tinkerer/Free Software Supporter ..
>>>
>>> Hi,
>>>
>>> Having that symbol in the System.map file depends on the kernel config
>>> symbol CONFIG_KALLSYMS.  KALLSYMS must be disabled (unset) for that
>>> symbol to be generated.  I don't know why it's like that.
>>>
>>> ffffffff815e50a8 B Version_197216
>>>
>>> Ted, do you have any idea about that?
>>>
>>> thanks.
>>
>> ah, git log tells us:
>>
>> commit 197dcffc8ba0ea943fee86e28e99cd9575799772
>> Author: Daniel Guilak <guilak@...ux.vnet.ibm.com>
>> Date:   Fri Jul 25 01:45:50 2008 -0700
>>
>>     init/version.c: define version_string only if CONFIG_KALLSYMS is not defined
>>     
>>     int Version_* is only used with ksymoops, which is only needed (according
>>     to README and Documentation/Changes) if CONFIG_KALLSYMS is NOT defined.
>>     Therefore this patch defines version_string only if CONFIG_KALLSYMS is not
>>     defined.
>>     
>>     Signed-off-by: Daniel Guilak <daniel@...ielguilak.com>
>>     Cc: Randy Dunlap <randy.dunlap@...cle.com>
>>     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>>     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
>>
>>
>> I would be OK with reverting that commit so that Version_xxxxxx is
>> always present in System.map.


-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ