linux-kernel - Re: [PATCH] firmware: declare __{start,end}_builtin

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:	Sun, 26 Jun 2016 11:24:49 +0200
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	Vegard Nossum <vegard.nossum@...cle.com>
Cc:	Ming Lei <ming.lei@...onical.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] firmware: declare __{start,end}_builtin_fw as pointers

On 25 June 2016 at 23:06, Vegard Nossum <vegard.nossum@...il.com> wrote:
> On 25 June 2016 at 17:04, Vegard Nossum <vegard.nossum@...cle.com> wrote:
>> The test in this loop:
>>
>>   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
>>
>> was getting completely compiled out by my gcc, 7.0.0 20160520. The result
>> was that the loop was going beyond the end of the builtin_fw array and
>> giving me a page fault when trying to dereference b_fw->name inside
>> strcmp().
>>
>> I strongly suspect it's because __start_builtin_fw and __end_builtin_fw
>> are both declared as (separate) arrays, and so gcc conludes that b_fw can
>> never point to __end_builtin_fw.
>>
> I see the __start_foo[]/__end_foo[] idiom is used a lot in the kernel
> so this could potentially be a problem in other places as well. The
> best solution may be a compiler flag (if it exists). I'll play a bit
> more with it to see if I can come up with something.

This is the best I could come up with: assuming gcc is not allowed to
reason about what's inside the asm(), this is the only way I could
think of to lose the array information without incurring unnecessary
overheads. It should also be relatively safe as there is no way to
accidentally use the underlying arrays without explicitly declaring
them.

I've not run-tested the final version of the patch yet (as I have to
run), but I did successfully boot an earlier version which was only
cosmetically different (I think).


Vegard

View attachment "0001-firmware-declare-__-start-end-_builtin_fw-as-pointer.patch" of type "text/x-patch" (2734 bytes)