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: <20100824213931.GA1192@router-fw-old.local.net-space.pl>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ