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]

Message-ID: <CAB=NE6Wae+FE+aYjJt0zEsqKx8XYfO31af0rrAOoW2KC7V2iFg@mail.gmail.com>
Date:	Fri, 22 Jan 2016 13:52:40 -0800
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	"H. Peter Anvin" <hpa@...or.com>
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>,
	andreyknvl@...gle.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 Fri, Jan 22, 2016 at 11:06 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 01/22/2016 05:44 AM, Michael Matz wrote:
>> Hi,
>>
>> On Thu, 21 Jan 2016, H. Peter Anvin wrote:
>>
>>> Something that confuses me is that gcc seems to give these sections the
>>> "aw" attributes which makes as complain.  This might be a gcc bug.
>>
>> Workaround: use an (possibly empty) intializer:
>>
>> struct foo {int i;};
>> const struct foo
>> __attribute__((used,section(".rodata.tbl.tablename.0"))) tablename[0] = {};
>>
>
> And indeed that works.  Awesome!  Much better than having to do an
> assembly hack.

BTW before we set these in stone given that subarch (lguest, Xen, PC)
really does provide a split in run time code we *know* we could
technically free code for subarchs not needed. I don't expect this to
happen now, but its possibility to do later seems worthy for us to
consider on architecture here on the way we define the linker tables.
As I have it linker tables are associated associated with a struct
(which hpa asked to enable anyone to peg *anything* not just structs),
these structs then have a priority which uses the linker later to sort
things for us, and it also has a subarch bitmask which tells us the
supported subarchs.

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.

 Luis