linux-kernel - Re: [GIT PULL] x86 setup BIOS workarounds

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:	Thu, 02 Apr 2009 00:15:20 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Michael K. Johnson" <johnsonm@...th.com>,
	Justin Forbes <jmforbes@...uxtx.org>,
	Jordan Hargrave <Jordan_Hargrave@...l.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org
Subject: Re: [GIT PULL] x86 setup BIOS workarounds


> +		/* ACPI 3.0 added the extended flags support.  If bit 0
> +		   in the extended flags is zero, we're supposed to simply
> +		   ignore the entry -- a backwards incompatible change! */
> +		if (size > 20 && !(buf.ext_flags & 1))
> +			continue;


At the risk of rushing to the defense of the ACPI spec...

This does not look like a backwards incompatible change to me.

In ACPI 2.0, size of 20 is always returned, and it would
be a Linux bug if we examined the undefined values after byte 19.

In ACPI 3.0, byte 20 is now defined.  So if the BIOS returns
a size >= 21, we are permitted to examine byte 20.

So I agree with the test above, but I do not agree with the comment.

thanks,
Len Brown, Intel Open Source Technology Center

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