linux-kernel - Re: [PATCH 1/1] module: fix symbol versioning with symbol prefixes

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: <8738vyvoy0.fsf@rustcorp.com.au>
Date:	Thu, 14 Mar 2013 10:21:19 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	James Hogan <james.hogan@...tec.com>
Cc:	linux-kernel@...r.kernel.org, James Hogan <james.hogan@...tec.com>,
	Michal Marek <mmarek@...e.cz>, Sam Ravnborg <sam@...nborg.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jonathan Kliegman <kliegs@...omium.org>
Subject: Re: [PATCH 1/1] module: fix symbol versioning with symbol prefixes

James Hogan <james.hogan@...tec.com> writes:
> Fix symbol versioning on architectures with symbol prefixes. Although
> the build was free from warnings the actual modules still wouldn't load
> as the ____versions table contained unprefixed symbol names, which were
> being compared against the prefixed symbol names when checking the
> symbol versions.
>
> This is fixed by modifying modpost to add the symbol prefix to the
> ____versions table it outputs (Modules.symvers still contains unprefixed
> symbol names). The check_modstruct_version() function is also fixed as
> it checks the version of the unprefixed "module_layout" symbol which
> would no longer work.

Hmm, this has always been broken, right?  And noone noticed?  Unless you
really want it now, I'll queue it for *next* merge window.

I've applied it (reworked) to my pending-rebases queue, and will put it
in modules-next once the cleanup goes in.

Thanks,
Rusty.

From: James Hogan <james.hogan@...tec.com>
Subject: module: fix symbol versioning with symbol prefixes

Fix symbol versioning on architectures with symbol prefixes. Although
the build was free from warnings the actual modules still wouldn't load
as the ____versions table contained unprefixed symbol names, which were
being compared against the prefixed symbol names when checking the
symbol versions.

This is fixed by modifying modpost to add the symbol prefix to the
____versions table it outputs (Modules.symvers still contains unprefixed
symbol names). The check_modstruct_version() function is also fixed as
it checks the version of the unprefixed "module_layout" symbol which
would no longer work.

Signed-off-by: James Hogan <james.hogan@...tec.com>
Cc: Michal Marek <mmarek@...e.cz>
Cc: Sam Ravnborg <sam@...nborg.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Jonathan Kliegman <kliegs@...omium.org>
Signed-off-by: Rusty Russell <rusty@...tcorp.com.au> (updated for cleanup)

diff --git a/kernel/module.c b/kernel/module.c
index cfd4a3f..3c2c72d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1212,7 +1212,8 @@ static inline int check_modstruct_version(Elf_Shdr *sechdrs,
 	if (!find_symbol(VMLINUX_SYMBOL_STR(module_layout), NULL,
 			 &crc, true, false))
 		BUG();
-	return check_version(sechdrs, versindex, "module_layout", mod, crc,
+	return check_version(sechdrs, versindex,
+			     VMLINUX_SYMBOL_STR(module_layout), mod, crc,
 			     NULL);
 }
 
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 6985021..909b5e7 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1927,7 +1927,8 @@ static int add_versions(struct buffer *b, struct module *mod)
 				s->name, mod->name);
 			continue;
 		}
-		buf_printf(b, "\t{ %#8x, \"%s\" },\n", s->crc, s->name);
+		buf_printf(b, "\t{ %#8x, \"%s%s\" },\n", s->crc,
+			   VMLINUX_SYMBOL_PREFIX_STR, s->name);
 	}
 
 	buf_printf(b, "};\n");
--
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/