linux-kernel - Re: Modversions and long symbol 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] [day] [month] [year] [list]

Date:	Wed, 28 Jan 2009 23:38:56 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Shawn Bohrer <shawn.bohrer@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Modversions and long symbol names

On Wednesday 21 January 2009 04:06:36 Shawn Bohrer wrote:
> Currently when modversions is enabled the kernel will not load any
> modules that depend on exported symbols with names longer than
> 64 - sizeof(unsigned long) characters.
> 
> This is because the struct modversion_info has the name member set to a
> size of MODULE_NAME_LEN.  This is not the module name this is the symbol
> name so I'm guessing this is a mistake or at least a misused constant.

Yes, it's overloaded.

> Is it possible to increase this size to something more reasonable like
> 512 characters?

Oh, you almost had me.  Almost.

This *looks* like the kind of naive question a newbie would ask.  And a poor coder would simply patch in the increase.  A reasonable coder would also make a comment about the potential bloat.  A good coder would ask why you need more than fifty_five_characters_in_one_single_exported_identifier.

But you're operating on a completely different level!

You chose this example to demonstrate, by (if I may) expandio ad absurdum, that our current approach is flawed.  Obviously you *knew* that it could be converted to a pointer, and equally obviously this would require us to process relocations before parsing version symbols.  Clearly, you understood that this would mean we had to find another solution for struct module versioning, but you knew that that was always the first symbol version anyway.

You no-doubt knew that we could potentially save 7% on our module size using this approach.  But obviously not wanting to criticize my code, you instead chose this oh-so-subtle intimation where I would believe the triumph to be mine alone!

I am humbled by your genius, and I only hope that my patch series approaches the Nirvanic perfection you foresaw.

Kudos Shawn, kudos!
Rusty.
--
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/