linux-kernel - Re: [RFC] module: signature infrastructure

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:	Thu, 06 Sep 2012 17:25:27 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Lucas De Marchi <lucas.de.marchi@...il.com>
Cc:	David Howells <dhowells@...hat.com>, dmitry.kasatkin@...el.com,
	zohar@...ux.vnet.ibm.com, jmorris@...ei.org,
	keyrings@...ux-nfs.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC] module: signature infrastructure

Lucas De Marchi <lucas.de.marchi@...il.com> writes:
> Sorry to come up with this suggestion only now (and after you have
> already talked to me at LPC). Only after seeing this implementation I
> thought about the implications of having the module signed in this
> format.
...
> I'm worried about performance here. Module loading can take a fair
> amount of boot time. It may not be critical for servers or desktops
> that we rarely boot, but it is for embedded uses.
...
> Letting it in be32 is the simplest solution IMO. it's way simpler then
> the loop above.
...
>> Scanning the module is the least of our issues since we've just copied
>> it and we're about to SHA it.
>
> Yeah, but I don't think we need to scan it one more time. On every
> boot. For every module

Regretfully, I don't have Linus' talent for flamage.

There's no measurable performance impact.  Scanning 1k takes about
5usec; we've wasted about enough time on this subject to load a billion
kernel modules.

I know this.  Not because I'm brilliant, but because I *measured* it.  I
even pulled out my original module signature signing check code, and
that was both faster and simpler.  See below.

Your assertion that the length-prepended version is "way simpler" is
wrong.  Again, I know this because I *read the code*:

        https://git.kernel.org/?p=linux/kernel/git/kasatkin/linux-digsig.git;a=commitdiff;h=19eef6e4e529ccf2b3a6ab5c19dd40f2eaf8fcaf

Don't send any more lazy, unthoughtful mails to the list.  It's
disrespectful and makes me grumpy.

Rusty.
PS.  Pushed updated version to my kernel.org linux.git/module-signing branch.

#ifdef CONFIG_MODULE_SIG
static int module_sig_check(struct load_info *info,
			    const void *mod, unsigned long *len)
{
	int err = 0;
	const unsigned long markerlen = strlen(MODULE_SIG_STRING);
	const void *p = mod, *end = mod + *len;

	/* Poor man's memmem. */
	while ((p = memchr(p, MODULE_SIG_STRING[0], end - p))) {
		if (p + markerlen > end)
			break;

		if (memcmp(p, MODULE_SIG_STRING, markerlen) == 0) {
			const void *sig = p + markerlen;
			/* Truncate module up to signature. */
			*len = p - mod;
			err = mod_verify_sig(mod, *len,
					     sig, end - sig,
					     &info->sig_ok);
			break;
		}
		p++;
	}

	/* Not having a signature is only an error if we're strict. */
	if (!err && !info->sig_ok && sig_enforce)
		err = -EKEYREJECTED;
	return err;
}
--
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/