linux-kernel - RE: [PATCH] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

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:	Fri, 18 Apr 2014 03:00:21 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"Zhao, Yakui" <yakui.zhao@...el.com>
Subject: RE: [PATCH] ACPICA: Tables: Skip NULL entries in RSDT and XSDT.

Hi, Greg

> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> Sent: Friday, April 18, 2014 10:44 AM
> 
> On Fri, Apr 18, 2014 at 09:53:19AM +0800, Lv Zheng wrote:
> > Note that this patch is only used for stable kernels, upstream kernels
> > will have this problem fixed in ACPICA 201303-04 release.  So upstream
> > kernels shouldn't merge this commit.
> 
> What kernel commit fixed this issue in "upstream"?

There is no kernel commit now has fixed this issue in "upstream".
The fix commit need to go into ACPICA first, so I believe it will appear in 3.15-rc2 (ACPICA 201403xx release) or 3.15-rc3 (ACPICA 201404xx release).

The back port of the fix commit will have many dependencies as we have a big change in ACPICA table manager in ACPICA 201403xx release.
However this back port is very light and has been confirmed by the reporters.

The bug seems to be urgent, it has broken many platforms shipped with AMI BIOSes versioning from F2 to F4.
Someone may monitor here to find a valid fix.

Best regards
-Lv

> 
> > It is reported that there are buggy BIOSes in the world: AMI uses a XSDt
> > compiler for early BIOSes, this compiler will generate XSDT with a NULL
> > entry.  The affected BIOS versions are "AMI BIOS F2-F4".
> >
> > Original solution on Linux is to use an alternative heathy root table
> > instead of the ill one.  This commit is refined by the following ACPICA
> > commit that tries to reduce the source code differences between Linux and
> > ACPICA upstream.
> >   Commit: 671cc68dc61f029d44b43a681356078e02d8dab8
> >   Subject: ACPICA: Back port and refine validation of the XSDT root table.
> > But according to the bug report, the XSDT in fact is not broken, we should
> > just add NULL entry sanity check before installing a table address from
> > XSDT.
> >
> > With the NULL entry sanity check implemented, the XSDT validation is
> > useless because:
> > 1. If XSDT contains NULL entries, it can be bypassed by the new sanity
> >    check mechanism;
> > 2. If RSDP contains a bad XSDT address, invoking XSDT validation will still
> >    lead to kernel crash.
> >
> > This patch deletes XSDT validation logics and adds code to skip NULL
> > entries that can be found in RSDT or XSDT. Lv Zheng.
> >
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=73911
> > Buglink: https://bugs.archlinux.org/task/39811
> > Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> > Reported-and-tested-by: Bruce Chiarelli <mano155@...il.com>
> > Reported-and-tested-by: Spyros Stathopoulos <spystath@...il.com>
> > Cc: Zhao Yakui <yakui.zhao@...el.com>
> > Cc: <stable@...r.kernel.org> # 3.14.x: 671cc68: ACPICA: Back port and refine validation of the XSDT root table.
> 
> So this fix is only needed for 3.14?  Or older?  I'm confused here...
> 
> greg k-h
--
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/