linux-kernel - Re: CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled

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, 2 Feb 2016 19:18:31 +0300
From:	Andrey Ryabinin <aryabinin@...tuozzo.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Mike Krinkin <krinkin.m.u@...il.com>,
	<linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled



On 02/02/2016 01:21 AM, Andrew Morton wrote:
> On Mon, 1 Feb 2016 18:10:38 +0300 Andrey Ryabinin <aryabinin@...tuozzo.com> wrote:
> 
>> On 01/30/2016 03:36 AM, Mike Krinkin wrote:
>>> Hi,
>>>
>>> option CONFIG_UBSAN_ALIGNMENT breaks x86-64 kernel with lockdep enabled,
>>> i. e kernel with CONFIG_UBSAN_ALIGNMENT fails to load without even any
>>> error message.
>>>
>>> The problem is that ubsan callbacks use spinlocks and might be called
>>> before lockdep is initialized. Particularly this line in the
>>> reserve_ebda_region function causes problem:
>>>
>>> lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
>>>
>>> If i put lockdep_init() before reserve_ebda_region call in
>>> x86_64_start_reservations kernel loads well. Since CONFIG_UBSAN_ALIGNMENT
>>> isn't useful for x86 anyway it might be better to disable this option for
>>> x86 arch?
>>>
>>
>>
>> Alignment checks could be useful even on x86, because there are unaligned accesses in generic code.
>> I think we can disable alignment instrumentation for arch/x86 directory only.
> 
> It looks pretty simple to make lockdep self-initialize on demand.  I
> don't think it'll affect performance much at all and it takes away all
> these "has lockdep initialized yet" concerns?
> 

Yes, this seems a better choice. 
It also should protect us from possible undefined behavior that someday may appear in early code.
Your patch works for me.