linux-kernel - Re: [PATCH] EDD: Check for correct EDD 3.0 length

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: <20120515150005.GG6948@redhat.com>
Date:	Tue, 15 May 2012 18:00:05 +0300
From:	Gleb Natapov <gleb@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Hannes Reinecke <hare@...e.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH] EDD: Check for correct EDD 3.0 length

On Tue, May 15, 2012 at 03:54:50PM +0100, Alan Cox wrote:
> > > Sample case of .. 1
> > > 
> > Not one. Any system with SCSI disk. Revert the patch and check on yours.
> 
> I don't have a SCSI disk. In fact most users don't have a SCSI disk 8)
> 
Most of them have SATA which is not even defined by Phoenix spec 8)

> > > Actual systems in the field are using both 3.0 and 4.0 so we need to deal
> > > with that as part of fixing this. That is the reality of the situation.
> > Again let me correct myself. This is not about 3.0 versus 4.0. This is
> > about Phoenix vs T13 spec. The code was written to support only T13.
> 
> Well actually the code was written to mishandle both in different ways.
This is simply not true. The code defines device path structure
according to T13 spec and clearly states in the header which spec it was
written to support. May be this is not clear from the thread but the code
still provides every other information except device path from Phoenix
EDD. You can still see pci device from /sys/firmware/edd/int13_80.

> You propose to change it to handle one correctly and completely fail on
> the other. That isn't what needs to happen.
> 
Not completely fail, only suppress information the code does not know
how to parse!

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