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: <20120515144810.GE6948@redhat.com>
Date:	Tue, 15 May 2012 17:48:10 +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:36:14PM +0100, Alan Cox wrote:
> On Tue, 15 May 2012 17:21:29 +0300
> Gleb Natapov <gleb@...hat.com> wrote:
> 
> > On Tue, May 15, 2012 at 03:18:49PM +0100, Alan Cox wrote:
> > > On Tue, 15 May 2012 17:12:14 +0300
> > > Gleb Natapov <gleb@...hat.com> wrote:
> > > 
> > > > On Tue, May 15, 2012 at 02:49:45PM +0100, Alan Cox wrote:
> > > > > > I do not see support for other spec to be important, but you are welcome
> > > > > > to write support for it if you need it. The only way I see to check what
> > > > > > spec edd info corresponds to is to calculate checksum according to both
> > > > > > specs and see which one succeeds.
> > > > > 
> > > > > No it doesn't work like that. This is a regression for existing working
> > > > > systems. It needs to be reverted or fixed. If it was a new feature you'd
> > > > > have a point - but it isn't. You've broken stuff, undo the breakage.
> > > > > 
> > > > Code never supported anything but EDD4.0 spec. I checked history git.
> > > > Code erroneously tried to interpret EDD3.0 info according to EDD4.0 spec
> > > > providing garbage as a result.
> > > 
> > > Providing some valid data and info, which has now disappeared.
> > > 
> > False. See my other mail:
> > 
> > # cat /sys/firmware/edd/int13_dev80/interface
> > SCSI            id: 0  lun: 1224979098644774912
> > 
> > This is what I got on my system. How is it useful?
> 
> Sample case of .. 1
> 
Not one. Any system with SCSI disk. Revert the patch and check on yours.

> Have you checked how the various distribution grub installers and the
> like respond to the various changes or having bits of their edd data
> vanish mysteriously ?
> 
That's how I entered this mess in the first place. Fedora/RHEL installer
didn't check edd info at all (no wonder, it was useless). It used mbr
signature to match HDD to int13. For vitalization this approach does not
work since usually disk images are unformatted, so I wanted to use EDD
info. That is when I found this bug and that phoenix EDD3 does not
provide enough info to match even basic things like ATA or SCSI.

> It's been this way for a long time, there is no rush to fix it. So we
> should fix it properly not break stuff.
> 
> 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.

> 
> 1.1 I suspect we can not care about.
> 
> Alan

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