linux-kernel - Re: [tip:x86/urgent] x86, apic: Fix apic=debug boot crash

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, 24 Aug 2010 23:39:31 +0200
From:	Daniel Kiper <dkiper@...-space.pl>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Daniel Kiper <dkiper@...-space.pl>, mingo@...hat.com,
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, apic: Fix apic=debug boot crash

Hello,

On 08/23/2010 07:54 AM, H. Peter Anvin wrote:
> It's already applied.

Thx.

On Mon, Aug 23, 2010 at 10:59:19AM -0700, Yinghai Lu wrote:
[...]
> >>>> x86, apic: Fix apic=debug boot crash
> >>>>
> >>>> Fix a boot crash when apic=debug is used and the APIC is
> >>>> not properly initialized.
> >>>>
> >>>> This issue appears during Xen Dom0 kernel boot but the
> >>>> fix is generic and the crash could occur on real hardware
> >>>> as well.
> >>>
> >>> Do you have any report on real hardware?
> >>> that could not happen on real hardware.
> >>
> >> Till now no, however I think it is good idea
> >> to apply this patch now. It is not worth to wait
> >> for another null pointer dereference.
>
> no, we should add BUG_ON() etc debug info there to see why that null cfg could happen.
> because according to code, we should have null there.

I think that BUG_ON() is too strong here because
it is "debug" function and it should work also
with let's say "invalid" data (in Xen case it is
normal because APIC state is managed directly
by hypervisor).

Additionally, with this patch it is easy to
differentiate between cfg != NULL and
cfg == NULL. Please look below:

cfg != NULL:
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.

cfg == NULL:
IRQ to pin mappings:
.................................... done.

If I missed something or if you have any
questions please drop me a line.

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