linux-kernel - Re: [PATCH v2 4/4] kernel: add support for init

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:	Mon, 9 Sep 2013 20:15:29 -0400
From:	Kyle McMartin <kyle@...radead.org>
To:	Frantisek Hrbata <fhrbata@...hat.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Kyle McMartin <kyle@...radead.org>,
	linux-kernel@...r.kernel.org, jstancek@...hat.com,
	keescook@...omium.org, peter.oberparleiter@...ibm.com,
	linux-arch@...r.kernel.org, arnd@...db.de, mgahagan@...hat.com,
	agospoda@...hat.com, akpm@...ux-foundation.org
Subject: Re: [PATCH v2 4/4] kernel: add support for init_array constructors

On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
> I'm not sure if coexistence of .ctors and .init_array sections should result in
> denial of module, but I for sure know nothing about this :). Could you maybe
> privide one example of the "weird thing"?
> 

They shouldn't exist unless placed there intentionally... I suspect a
call_if_changed Makefile target to regenerated a header would solve this
problem sufficiently for a given toolchain version.

A little exposition:
.init_array and .ctors are laid out on top of each other, with an
ordering that's a bit complicated... the sort of the ctor functions ends
up being .ctor.x upwards towards 65535, and .init_array.x downwards
from 65535 towards 0, with priority 65535-x, so that

.init_array.32768 would be called before .ctor.32768.

It's all a complete mess.

Perhaps if CONFIG_GCOV is on, we should enforce MODVERSIONS and make
sure the GCC version doesn't change for the running kernel?

Maybe it would be sufficient to just detect what the toolchain supports
and do that? I have a patch based on the configure.ac in gcc that
does something like that, which would be trivial to use to generate a
header based on gcc version.

> Anyway many thanks for taking time to look at this. Below is my attepmt to
> implement the check you proposed. 
> 
> untested/uncompiled

regards, Kyle
--
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/