linux-kernel - Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA

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: <ee3242f9-1fab-f3a8-947d-85fc1a660a49@suse.cz>
Date:   Wed, 22 Mar 2017 08:39:40 +0100
From:   Jiri Slaby <jslaby@...e.cz>
To:     Ingo Molnar <mingo@...nel.org>, Pavel Machek <pavel@....cz>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Cc:     mingo@...hat.com, tglx@...utronix.de, hpa@...or.com,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        xen-devel@...ts.xenproject.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Len Brown <len.brown@...el.com>, linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for
 data

On 03/22/2017, 08:25 AM, Ingo Molnar wrote:
> 
> * Pavel Machek <pavel@....cz> wrote:
> 
>> Hi!
>>
>>> -ENTRY(saved_rbp)	.quad	0
>>> -ENTRY(saved_rsi)	.quad	0
>>> -ENTRY(saved_rdi)	.quad	0
>>> -ENTRY(saved_rbx)	.quad	0
>>> +SYM_DATA_START(saved_rbp)		.quad	0
>>> +SYM_DATA_START(saved_rsi)		.quad	0
>>> +SYM_DATA_START(saved_rdi)		.quad	0
>>> +SYM_DATA_START(saved_rbx)		.quad	0
>>
>> Does it make sense to call it SYM_DATA_*START* when there's no
>> corresponding end?
> 
> That looks like a bug - I think we should strive for them to always be in pairs.
> 
> Jiri, Josh, could objtool help here perhaps, to detect 'non-terminated' 
> SYM_*_START() uses? This could be done by emitting debug data into a special 
> section and then analyzing that section for unpaired entries. The section can be 
> discarded in the final link, it won't show up in the kernel image.

It should be easier than that. No introduction of other info needed --
every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should
be a bug now.

> We don't ever nest symbols, right?

AFAI could see so far, correct.

>> Plus... it looks like saved_rsi (and friends) are only used inside
>> wakeup_64.S. Could we just delete the "ENTRY" annotations?
> 
> That appears to make sense as well.

+1, will fix this.

thanks,
-- 
js
suse labs