LKML Archive on
help / color / mirror / Atom feed
From: Andries Brouwer <>
To: Linus Torvalds <>
Subject: Re: rfc: test whether a device has a partition table
Date: Thu, 25 Sep 2003 13:42:17 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Sep 24, 2003 at 09:47:01PM -0700, Linus Torvalds wrote:

> On Thu, 25 Sep 2003, Andries Brouwer wrote:

> > My post implicitly suggested the minimal thing to do.
> > It will not be enough - heuristics are never enough -
> > but it probably helps in most cases.
> I don't mind the 0x00/0x80 "boot flag" checks - those look fairly obvious
> and look reasonably safe to add to the partitioning code.
> There are other checks that can be done - verifying that the start/end
> sector values are at all sensible. We do _some_ of that, but only for
> partitions 3 and 4, for example. We could do more - like checking the
> actual sector numbers (but I think some formatters leave them as zero).
> Which actually makes me really nervous - it implies that we've probably 
> seen partitions 1&2 contain garbage there, and the problem is that if 
> you're too careful in checking, you will make a system unusable.

No and yes.

Note that all checks that are there today are mine.
No, the missing check on 1&2 does not mean that there may be garbage there,
it was just the other way around. In a chain of logical partitions inside
an extended partition almost always only slots 1 and 2 are used, and
slots 3 and 4 are zeroed out. But it happens that slots 3 and 4 are used,
so we want to look at them. But sometimes slots 3 and 4 contain complete
garbage, so we trust them much less than slots 1 and 2, and accept them only
when everything really looks right.

It is possible to add more checks, and each time there was reason to do so
we added the minimal check.

> And your random byte checks for power-of-2 make no sense. What are they
> based on?

First you say that they make no sense and then you ask why they make sense?
You might as well just ask.

I don't know whether you want a general or a technical answer.
Let us try the technical one. A FAT bootsector has in bytes 11-12
a little-endian short that gives the number of bytes per sector.
It is almost always 512, but also 1024, 2048, 4096 occur.
A FAT bootsector has in byte 13 the number of sectors per cluster.
It is usually 1, but also 2, 4, 8, 16, 32, 64, 128 occur.

Thus, it is a reasonable test to check these three bytes and
require two powers of two. If that fails, then we do not have
a FAT bootsector (of a type I have ever seen).


  parent reply	other threads:[~2003-09-25 11:42 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-24 20:29 Andries.Brouwer
2003-09-24 21:54 ` Linus Torvalds
2003-09-24 23:50   ` Andries Brouwer
2003-09-25  0:05     ` viro
2003-09-25 12:14       ` Andries Brouwer
2003-09-25  0:18     ` Linus Torvalds
2003-09-25  6:53       ` Xavier Bestel
2003-09-25 10:57       ` Andries Brouwer
2003-09-25  4:47     ` Linus Torvalds
2003-09-25  4:56       ` Linus Torvalds
2003-09-25 11:42       ` Andries Brouwer [this message]
2003-10-05  9:00   ` Meelis Roos
2003-09-25  0:42 ` Douglas Gilbert
2003-09-25  1:00   ` viro
2003-09-25  1:27     ` Douglas Gilbert
2004-05-22 11:18 Uwe Bonnes
2004-05-22 12:37 ` John Bradford
2004-05-22 12:56 ` Andries Brouwer
2004-05-22 15:14   ` Uwe Bonnes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: rfc: test whether a device has a partition table' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).