linux-kernel - Re: mod_devicetable: Make dmi

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]

Date:	Tue, 19 May 2015 16:56:30 +0100
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	Joe Perches <joe@...ches.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	LKML <linux-kernel@...r.kernel.org>,
	Quentin Casasnovas <quentin.casasnovas@...cle.com>
Subject: Re: mod_devicetable: Make dmi_strmatch.substr const char *

On Tue, 19 May 2015 07:46:58 +0100
David Woodhouse <dwmw2@...radead.org> wrote:

> On Mon, 2015-05-18 at 17:07 -0700, Joe Perches wrote:
> > 
> > changed dmi_strmatch.substr from char * to char[79];
> > 
> > Changing it back to const char * would shrink an x86-64
> > defconfig more than 100KB.
> > 
> > $ size vmlinux.old vmlinux.new
> >     text    data     bss      dec    hex filename
> > 11941725 1825624 1085440 14852789 e2a2b5 vmlinux.old
> > 11921172 1730648 1085440 14737260 e0df6c vmlinux.new

What percentage of those are __initdata ?

> > modpost has changed a bit since 2008, is it's time to change it back?
> 
> Does the match table stuff still work if you do that? I thought the
> point in changing to an array was to make the table extraction do the
> right thing because it can't follow pointers...

Can't follow, or can't currently follow. All the data needed appears to
exist.

If you are trying to build a compact kernel with no modules then you can
certainly make them pointers. A more serious and invasive fix would be to
make substr a u32 and replace the text in the match with a Rabin-Karp or
other rolling hash value, then do a rolling hash for the match. As we've
got zlib in the kernel I assume we have the hash to hand ?

The same could be applied to a lot of the other matchers although with
drastically reduced results as they don't have 320 bytes of match
bloating each single entry.

It does however mean something would have to do the substitutions at
compile time, either by writing the rolling hash as a recursive
preprocessor macro or having a tool in the path which is ugly.

Alan

--
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/