linux-kernel - Re: [PATCH 1/4] kernel: constructor support

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: <4A041625.5060408@linux.vnet.ibm.com>
Date:	Fri, 08 May 2009 13:23:17 +0200
From:	Peter Oberparleiter <oberpar@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Huang Ying <ying.huang@...el.com>, Li Wei <W.Li@....COM>,
	Michael Ellerman <michaele@....ibm.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Sam Ravnborg <sam@...nborg.org>, Jeff Dike <jdike@...toit.com>
Subject: Re: [PATCH 1/4] kernel: constructor support

Ingo Molnar wrote:
> * Peter Oberparleiter <oberpar@...ux.vnet.ibm.com> wrote:
>> Ingo Molnar wrote:
>>> * Peter Oberparleiter <oberpar@...ux.vnet.ibm.com> wrote:
>>>
>>>> Disable constructor support for usermode Linux to prevent conflicts
>>>> with host glibc.
>>>> +++ linux-2.6.30-rc4/init/Kconfig
>>>> @@ -16,6 +16,11 @@ config DEFCONFIG_LIST
>>>>  	default "$ARCH_DEFCONFIG"
>>>>  	default "arch/$ARCH/defconfig"
>>>>  +config CONSTRUCTORS
>>>> +	bool
>>>> +	depends on !UML
>>>> +	default y
>>>> +
>>>>  menu "General setup"
>>> Hm, excluding UML like that is sad. Is there no better solution?
>> UML is excluded because in that environment constructors are 
>> called by the host glibc, so there is no need for kernel support 
>> on UML (in fact it would break things).
>>
>> Or were you referring to the actual way the exclusion is 
>> implemented?
> 
> the way it's done is OK (there's really just UML in this situation), 
> but the question is really, shouldnt it be possible to coverage-test 
> UML instances 'from the inside'?

 From a mere gcov perspective, coverage-testing from the outside is 
superior because that is the way it was meant to be run in the first place.

> 
> Plus, if any other kernel facility grows out of this or makes use of 
> it, UML will be left out in the cold.

I'm afraid that trying to over-engineer the gcov-kernel mechanism at 
this time might serve neither the gcov-kernel users, nor potential new 
users. Once the base is established, it will be far easier to decide 
which other purposes the infrastructure can serve (without completely 
bending it).

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