linux-kernel - Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches

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: <54084BF7.8090900@canonical.com>
Date:	Thu, 04 Sep 2014 13:24:39 +0200
From:	Maarten Lankhorst <maarten.lankhorst@...onical.com>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
CC:	Matt Fleming <matt@...sole-pimps.org>,
	Ulf Winkelvos <ulf@...kelvos.de>,
	Matt Fleming <matt.fleming@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [REGRESSION] "efi: efistub: Convert into static library" and
 preparation patches

Op 04-09-14 om 13:19 schreef Ard Biesheuvel:
>
>> On 4 sep. 2014, at 12:48, Maarten Lankhorst <maarten.lankhorst@...onical.com> wrote:
>>
>> Op 03-09-14 om 21:57 schreef Ard Biesheuvel:
>>> On 3 September 2014 19:59, Matt Fleming <matt@...sole-pimps.org> wrote:
>>>> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote:
>>>>> Will do, thanks.
>>>>>
>>>>> @Matt: so there is two ways to fix this, the patch above addressing
>>>>> this single instance, and alternatively, adding a #pragma GCC
>>>>> visiblilty push(hidden) to all .c files under libstub/, *before* the
>>>>> #includes. The latter would catch future problems regarding newly
>>>>> introduced global variables, but it may be a bit overkill in this
>>>>> case, as libstub is not expected to be in flux in the foreseeable
>>>>> future.
>>>>>
>>>>> Any preferences?
>>>> Any reason we can't reuse the existing GOT fixup code in the early x86
>>>> boot code? We're not executing it before the EFI boot stub atm, which is
>>>> the reason Maarten is hitting these difficulties.
>>> I guess that is likely to work, I just wasn't aware it existed :-)
>>> I think adding another visibility(hidden) attribute or 2 would
>>> complete eliminate the need for GOT fixups, but I guess that is more
>>> sensitive to compiler versions being recent enough etc.
>>> The attached (build tested only) patch eliminates all GOT relocations
>>> under boot/compressed for a 64-bit EFI stub build.
>>>
>>>> Maarten, does the following help?
>>>>
>>>> If not, Ard please go ahead with option #2 above. Overkill yes, but I've
>>>> done the single __attribute__() hacks in other projects and someone
>>>> (usually me) always eventually forgets to tag some instance.
>>> It appears we just got lucky on arm64, since we don't have any global
>>> variables, but the issue does exist there as well.
>> FWIW, visibility pushing doesn't seem to work for functions declared with extern.
> Are you sure you are seeing GOT entries being generated for functions? Normally, these are resolved via PLT entries, and those usually don't result in GOT entries to be allocated unless the branch target is unknown at link time.
>
No not really, I was just looking at GOTPCREL for the .o files, no idea if they resulted in any actual relocations or not.

~Maarten

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