linux-kernel - RE: [PATCH 2/2] fs/partition/msdos: Fix unusable extended partition for

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, 11 Mar 2010 14:06:03 -0800
From:	"Daniel Taylor" <Daniel.Taylor@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"OGAWA Hirofumi" <hirofumi@...l.parknet.co.jp>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] fs/partition/msdos: Fix unusable extended partition for > 512B sector

 

> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa@...or.com] 
> Sent: Thursday, March 11, 2010 1:58 PM
> To: Daniel Taylor
> Cc: OGAWA Hirofumi; Andrew Morton; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 2/2] fs/partition/msdos: Fix unusable 
> extended partition for > 512B sector
> 
> On 03/11/2010 01:25 PM, Daniel Taylor wrote:
> >
> > I have not yet tried booting from one of these disks.
> >
> > They are in USB-attached enclosures,
> 
> Right...
> 
> > attached well after boot, so the
> > bootloader has never seen them.
> 
> Wrong.  A lot of BIOSes will attempt to boot from USB 
> storage.  Worse, a 
> fair number of BIOSes will hang during startup if a USB 
> storage device 
> that confuses them -- even if not the primary boot device.

BIOS failures prior to loading the kernel are not Linux'
responsibility.  Confused BIOS will still fail, even if the
patch is not implemented,  so how does that effect the
acceptance of a patch that fixes post-boot behavior?
 
>> They simply refuse to mount to a running
>> Linux system because, when the storage for partition size and start was
>> expanded to 64-bit, no one bothered to fix the intermediate storage in
>> msdos.c, so the kernel cannot locate the start nor figure the size of
>> the partitions.
>>
>> Logically, this patch is not complicated.  The data types in msdos.c
>> are flat-out wrong, given that the real stored data is of type sector_t.
>> The intermediate variables should not be u32.
> 
> I would consider this a bugfix.  As such, it should be pushed outside 
> the merge window.
> 
> 	-hpa
> 
--
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/