linux-kernel - Re: Misc fixes for 2.6.27

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: <87wshvwl8v.fsf@basil.nowhere.org>
Date:	Tue, 02 Sep 2008 00:32:16 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	David Woodhouse <dwmw2@...radead.org>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: Misc fixes for 2.6.27

David Woodhouse <dwmw2@...radead.org> writes:
> +
> +static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
> +	{	/* Some DG33BU BIOS revisions advertised non-existent VT-d */

Are you sure it's non existent? A G33 chipset should have it in
hardware I thought.

I'm not sure this is really the right way to handle this anyways.
If there's ever a working BIOS it will be blacklisted too. And
normally BIOS bugs don't come in one board alone, but in a range
of them and then adding more and more identifiers is quite painful.

Better would be to add some generic sanity checks that catches
the issues these BIOS revisions are having.

> +		.callback = blacklist_iommu,
> +		.ident = "Intel DG33BU",
> +		{	DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
> +			DMI_MATCH(DMI_BOARD_NAME, "DG33BU"),
> +		}
> +	},

-Andi

-- 
ak@...ux.intel.com
--
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/