linux-kernel - Re: [RFC v1 0/8] x86/init: Linux linker tables

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, 02 Feb 2016 16:25:03 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"Luis R. Rodriguez" <mcgrof@...nel.org>
CC:	Michael Matz <matz@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andy Lutomirski <luto@...capital.net>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	Michael Brown <mcb30@...e.org>,
	Juergen Gross <jgross@...e.com>,
	Jan Beulich <JBeulich@...e.com>,
	Joerg Roedel <joro@...tes.org>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>,
	long.wanglong@...wei.com, qiuxishi@...wei.com,
	aryabinin@...tuozzo.com,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Valentin Rothberg <valentinrothberg@...il.com>,
	Peter Senna Tschudin <peter.senna@...il.com>,
	X86 ML <x86@...nel.org>, Michal Marek <mmarek@...e.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v1 0/8] x86/init: Linux linker tables

On 02/02/2016 04:22 PM, Luis R. Rodriguez wrote:
>>
>> Should it be possible to resuse free_init_pages() and/or
>> free_reserved_area() only for routines (members in the array in this
>> case of a struct of fns) that don't meet our subarch once we're done
>> iterating over the routies and know we can discard things we know we
>> can drop? Through a cursory glance, *I think* its possible as-is, we
>> would just need easy access to the respective start and end addresses
>> and I guess there lies the challenge. Question is, is would that be
>> clean enough for us? Or are there other things you can think of that
>> perhaps might make this prospect cleaner later to add?
>>
>> I figure better ask now for architectural purposes than later after merged.
> 
> I don't think its needed we iron out in a solution *now* to be able to
> free code we know we won't need at run time but having a solid
> understanding adding this feature later without much impact to users
> might be worthy. As such I was pursuing a very basic proof of concept
> to ensure this is possible first given I didn't hear back if folks
> were sure this might be possible. I don't think a proof of concept
> should take long so just want to get fleshed out.
> 

This applies to the specific subarch use rather than generic linker
tables, right?

	-hpa