Info on which initial sectors a BIOS will boot

[James Harris]

In another thread we were discussing how the BIOS might select which
hard disks are eligible to be booted. Some candidate theories about
the first sector on the disk were

* the first bytes of the sector must have certain low values
* the partition table needs to have an active partition

Well, I decided to take the plunge and use dd to try the options as
long as I was very careful! I changed the initial sectors of disks on
a server which has multiple drives. The findings were surprising and
are set out below.

The tests were run on a Phoenix BIOS dated mid 2006. It apparently
followed these rules.

If the sector does not end with 0x55, 0xaa
- the disk does not get booted
- (and Linux reports: unknown partition table)

If the sector ends in 0x55, 0xaa:
If the first byte of the sector is zero
- the BIOS will *not* boot the sector
If the first byte is nonzero (from 1 upwards)
- the BIOS *will* boot the sector

Significantly, nothing I did to the bootable/active flag made a
difference. It seems, therefore, that the partition table is
irrelevant to booting and is not examined. The only checks are of
exactly three bytes:

sector ends with 0x55 and 0xaa and begins with a non-zero byte

Of course, the BIOS can also provide arbitrarily complex options to
allow the user to choose which of the hard disks it should look at.
There's nothing we can do about that list and probably nothing we
would want to do so it is no loss. For the Phoenix BIOS, at least, it
seems that as it works through the disks that it was told to look at
by the user it will boot probably the first one that follows the above
rules.

HTH,
James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message
news:4d963c7b-a989-4eda...@w5g2000yqi.googlegroups.com...

> In another thread we were discussing how the BIOS might select which
> hard disks are eligible to be booted. Some candidate theories about
> the first sector on the disk were
>
> * the first bytes of the sector must have certain low values
> * the partition table needs to have an active partition
>

I've replied - apparently to your clone and not you - a few times. You've
got to talk to your clone ... ;-)
http://groups.google.com/group/alt.os.development/msg/d21730c03058e2df
http://groups.google.com/group/comp.lang.asm.x86/msg/4bf45464c4f0df2d


This is what I've learned:

1) BIOS POST validates that a boot record as bootable for either removable
or non-removable media. (IBM PS/2 tech. ref.)

2) Removable media - "diskette" - must contain valid code in the boot
record. (IBM PS/2 tech. ref.) What "valid" code means apparently varies:
opcodes greater than six (IBM PS/2 tech. ref.), or a certain number of
identical bytes to indicate the disk is blank (other sources). FYI,
removable media originally were floppies, but today includes cd-roms, dvds,
usb sticks, etc.

3) Non-removable media - "fixed disk" - must have an 0xAA55 signature at the
end of the boot record. (IBM PS/2 tech. ref.) FYI, non-removable media were
originally hard drives, but today are hard drives, solid state drives, etc.
I.e., non-ejectable.

4) CP/M-86 and PCDOS bootsectors don't use 0xAA55. Those bootsectors
have a disk sidedness (single or dual sided) indicator in that location.
(CP/M
documentation)

5) Windows 98 etc will write serial numbers in the date field of floppies.

6) A partition table has a boot flag for it's first byte to indicate which
of the partitions is bootable.

7) CS=0000h and IP=7C00h (IBM PS/2 tech. ref.)

8) Some clone machines set CS and IP incorrectly, but to the same entry
location 07C00h.

9) DL = 00h diskette, 80h fixed disk. PS/2, maybe other IBM compatibles,
have a value in DH which determines floppy or cd-rom for diskette. (IBM
PS/2 tech. ref.)

10) Int 18h or Int 19h for PnP BIOS called for boot failure to try another
device. (PnP BIOS specification)

11) Int 18h for Bios Boot spec. BIOS is called upon a boot failure to try
another device. (BIOS Boot specification)

12) ES:DI points to PnP Installation Check Structure (PnP spec. and BBS
spec.)


That said, I currently have one machine that *requires* 0xAA55 to boot
floppies, or I'm doing something wrong (unlikely IMO) ... I've not found a
reason for this or standard which describes the change. AISI, it's a direct
violation of the original IBM requirements. It's the only machine I'm aware
of that does so. It couldn't run CP/M without a modified bootsector.

> Significantly, nothing I did to the bootable/active flag made a
> difference. It seems, therefore, that the partition table is
> irrelevant to booting and is not examined.

The boot/active flag is irrelevant to booting *what*?

Irrelevant to booting one of the partitions (PBR code)? Oh, definately
not ... There would be no point in partitioning the device. There would be
no method to select a partition on that device.

Irrelevant booting the fixed disk's MBR? Yes, it's irrelevant for that ...

Did you use a filesystem that uses a partition table and is partitioned?
You said so, but this seems to imply it's not. Does the device have other
valid partitions? If you set another partition bootable and there is no
partition there, then there won't be any partition boot code there either
... I.e., the MBR boot code might check for valid PBR code before
attempting to boot the partition and not boot, or it might just check the
boot flag and execute garbage and crash.

> Of course, the BIOS can also provide arbitrarily complex options to
> allow the user to choose which of the hard disks it should look at.

And, the select switches, and cable selects, and ....

If you want to know about the BIOS, you need to read specifications with
BIOS in the title:

PnP BIOS Specification
PCI BIOS Specification
BIOS Boot Specification
Enhanced BIOS Services for Disk Drives specification
ATAPI Removable Media Device BIOS Specification
APM BIOS Interface Specification
BIOS32 Service Directory Specification
Enhanced Parallel Port BIOS Specification
System Management BIOS Reference Specification
etc.

And also, you will want to read any interface specifications, like IDE, ATA,
SATA, EDD, etc. They'll have a BIOS modification section too.

I feel you. I'm not interested in "reading" all those either ... :-)


There is some stuff in the PnP BIOS specification such as the PnP POST
process and alternate boot devices and boot order via "IPL priority" for PnP
BIOSes.

There is a bit of stuff in the ATAPI Removable Media Device BIOS
Specification - ATAPI floppies - especially BIOS functions.

There is a bit of stuff in the Enhanced BIOS Services for Disk Drives
specification - not to be confused with Phoenix Enhanced Disk Drive
specification - such as device parameter tables, BIOS geometry information,
mapping of disk drives to BIOS 80h, 81h, 82h, and extended Int 13h
functions, CHS geometry.

There is lots of stuff in the BIOS Boot Specification that may interest you
such as drive numbering of 80h or 81h, order of installation of Int 13h
routines which determines drive boot order, left over boot behavior from IBM
AT calling Int 18h, discussion of various aspects of POST process, BBS
pop-up menu and boot device selection, hard disk boot sectors usually call
Int 18h on failure, while floppies usually call Int 19h, only 80h and 00h
are bootable i.e., "IPL devices", etc. There is probably more in the PnP
specifications too.


Rod Pemberton

[Antoine Leca]

Rod Pemberton wrote:
> "James Harris" <james.h...@gmail.com> wrote in message
> news:4d963c7b-a989-4eda...@w5g2000yqi.googlegroups.com...
>> In another thread we were discussing how the BIOS might select which
>> hard disks are eligible to be booted. Some candidate theories about
>> the first sector on the disk were
>>
>> * the first bytes of the sector must have certain low values
>> * the partition table needs to have an active partition
>>
>

> This is what I've learned:

Interesting, much appreciated, I guess I'll keep a copy ;-)

> That said, I currently have one machine that *requires* 0xAA55 to boot
> floppies, or I'm doing something wrong (unlikely IMO) ...

What I have learned is that "usually" Operating Systems are doing the
obvious here and always put a 0xAA55 at the end of the first sector; as
with any rule there are exceptions, and a famous one (besides CP/M86 and
original PC-DOS) here is SCO Xenix, which "boot sector for floppy" did
not have that signature (did they really need that space?)

>> Significantly, nothing I did to the bootable/active flag made a
>> difference. It seems, therefore, that the partition table is
>> irrelevant to booting and is not examined.

As in, _your_ '06 BIOS does not inspect the partition table before
booting. As Rod says, this is pretty usual; albeit I am sure there are
BIOS out there which do inspect that and will not boot unless there is
only one active entry in the (perhaps completely fake) partition table.
At any rate, it is the code booted from the first sector, not the
firmware, which is supposed to read and interpret that table.


Antoine

[James Harris]

On Apr 3, 9:44 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message

>
> > In another thread we were discussing how the BIOS might select which
> > hard disks are eligible to be booted. Some candidate theories about
> > the first sector on the disk were
>
> > * the first bytes of the sector must have certain low values
> > * the partition table needs to have an active partition
>
> I've replied - apparently to your clone and not you - a few times.  You've
> got to talk to your clone ... ;-)

You replied but your comments appear to be out of date. (Sorry!) And
in the first link that's not my comment that you initially replied to
even though you initial quoted it as from me. You misquoted someone
else as me again recently. Maybe you are getting confused and that's
why you think I have a clone!

> http://groups.google.com/group/alt.os.development/msg/d21730c03058e2df
> http://groups.google.com/group/comp.lang.asm.x86/msg/4bf45464c4f0df2d

...

> This is what I've learned:

... snipped comments that are not on topic of HD boot sector
criteria ...

> 3) Non-removable media - "fixed disk" - must have an 0xAA55 signature at the
> end of the boot record. (IBM PS/2 tech. ref.)

Yes, and if they want to be bootable they cannot have a zero first
byte. (That's not an onerous requirement as opcode zero would not be
used as the first byte of a real piece of bootsector code.)

...

> > Significantly, nothing I did to the bootable/active flag made a
> > difference. It seems, therefore, that the partition table is
> > irrelevant to booting and is not examined.
>
> The boot/active flag is irrelevant to booting *what*?

To booting from the hard disk.

...

> Irrelevant booting the fixed disk's MBR?  Yes, it's irrelevant for that ...

Yes. An implication of this is that one could have a HD boot sector
which contains a partition table and which gets booted by the BIOS but
on which NONE of the partitions is marked active. It would then be up
to the MBR code to take appropriate action - probably either stop with
an error message or invoke int 0x18.

> Did you use a filesystem that uses a partition table and is partitioned?

No, I didn't *use* a filesystem at all.

> You said so,

I did?

> but this seems to imply it's not.  Does the device have other
> valid partitions?

In the tests I kept the partition table intact throughout except for
the boot flag. The disk had only one partition.

>  If you set another partition bootable and there is no
> partition there, then there won't be any partition boot code there either
> ...  I.e., the MBR boot code might check for valid PBR code before
> attempting to boot the partition and not boot, or it might just check the
> boot flag and execute garbage and crash.

I was looking to see which hard disk was chosen by the BIOS. After
that the next steps are controlled by the MBR.

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:e7febaac-a2b6-429b...@s7g2000yqm.googlegroups.com...

> On Apr 3, 9:44 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:

...

> > I've replied - apparently to your clone and not you - a few times.
> > You've got to talk to your clone ... ;-)
>
> You replied but your comments appear to be out of date. (Sorry!) And
> in the first link that's not my comment that you initially replied to
> even though you initial quoted it as from me.

Apparently, that was brought up in the thread and corrected ...

> You misquoted someone else as me again recently. Maybe you are
> getting confused and that's why you think I have a clone!

I thought the second link was you also, but you were just in the thread.
Those were only the two I cited because of content. Actually, you *were*
still in those threads ... They were only 3 years ago! You should remember
them. But, if you look, I think you've been involved in quite a few
conversations on this topic. They are archived and searchable.

> > This is what I've learned:
>
> ... snipped comments that are not on topic of
> HD boot sector criteria ...

You only left #3? Well, ok ...

> > 3) Non-removable media - "fixed disk" - must have an 0xAA55
> > signature at the end of the boot record. (IBM PS/2 tech. ref.)
>
> Yes, and if they want to be bootable they cannot have a zero first
> byte. (That's not an onerous requirement as opcode zero would not be
> used as the first byte of a real piece of bootsector code.)

It's now true for one machine...

> > > Significantly, nothing I did to the bootable/active flag made a
> > > difference. It seems, therefore, that the partition table is
> > > irrelevant to booting and is not examined.
>
> > The boot/active flag is irrelevant to booting *what*?
>
> To booting from the hard disk.
>

Not so, if the MBR code uses partitions, which is normal...
The MBR code must be able to determine which partition to boot in order
for the OS to boot. Otherwise, the MBR code runs, but no partition is
booted, and no OS boots. You point out below that an MBR that uses
partition
tables with none of the partitions marked active shouldn't boot any of them.

> Yes. An implication of this is that one could have a HD boot sector
> which contains a partition table and which gets booted by the BIOS but
> on which NONE of the partitions is marked active. It would then be up
> to the MBR code to take appropriate action - probably either stop with
> an error message or invoke int 0x18.

Yes, that's correct. The OS shouldn't boot since no partitions were marked
active (depending on the MBR code) ...

> > Does the device have other valid partitions?
>
> In the tests I kept the partition table intact throughout except for
> the boot flag. The disk had only one partition.
>

> I was looking to see which hard disk was chosen by the BIOS.

A) Shouldn't the default device be in your BIOS settings? There should be
an ordered list of devices that the BIOS attempts to boot. The BIOS will
try the first and boot it if it can, or move on to the next device. Or,
it'll try the device selected via BBS menu. If there is no BIOS list, your
devices should ordered via cable select or device pin header select.

B) AIUI, you only had one bootable partition total, and therefore (most
likely) only one HD with MBR code installed, and therefore only one HD with
an OS that could be booted. Yes? So, AISI, your machine is only capable of
booting that one device as it's currently configured. You should partition
and format a second HD. You should also format a floppy or USB stick and
copy over the utilities to make the second HD bootable and make the floppy
bootable. Pull the first HD. Boot. Make the second HD bootable. Boot
from it to verify. Now, reinstall the first HD. Make sure both devices are
in the BIOS list. If both are bootable, as they should be now, the BIOS
should attempt to boot the first and boot it. If you switch the order in
the BIOS, the second should boot.


Rod Pemberton

[James Harris]

On Apr 5, 2:29 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>

wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message

> On Apr 3, 9:44 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>

...

> > > 3) Non-removable media - "fixed disk" - must have an 0xAA55
> > > signature at the end of the boot record. (IBM PS/2 tech. ref.)
>
> > Yes, and if they want to be bootable they cannot have a zero first
> > byte. (That's not an onerous requirement as opcode zero would not be
> > used as the first byte of a real piece of bootsector code.)
>
> It's now true for one machine...

I doubt there will be many willing to run the same tests partly
because a lot of test machines have just one hard disk and partly
because of the risk of making such changes on a non-test machine ....
and partly due to the work involved. Nevertheless I posted the code so
that others can try it out if they want to.

Given that a machine which has a BIOS from one of the main
manufacturers has the requirement I guess there are lots of machines
that behave in the same way. The original and documented standards, as
you have pointed out, required only a signature of 0x55, 0xaa. I guess
the requirement of the first byte not being zero was added later but I
don't know when or what to. It would have made sense for that rule to
be part of the original spec because zero is not sensible in that
position if the sector is to hold executable code.

...

> > I was looking to see which hard disk was chosen by the BIOS.
>
> A) Shouldn't the default device be in your BIOS settings?  There should be
> an ordered list of devices that the BIOS attempts to boot.  The BIOS will
> try the first and boot it if it can, or move on to the next device.  Or,
> it'll try the device selected via BBS menu.  If there is no BIOS list, your
> devices should ordered via cable select or device pin header select.

Yes, I told the BIOS to boot from hard disk without specifying which
one so that it had to search through those which were attached. And I
verified that the test disk was examined by the BIOS before the OS-
carrying disk. (In fact I removed all the other disks so that the
machine had just two attached when testing.)

> B) AIUI, you only had one bootable partition total, and therefore (most
> likely) only one HD with MBR code installed, and therefore only one HD with
> an OS that could be booted.  Yes?

Yes, to start with. But I tried adding the bootable-partition flag to
the test disk both with and without having the first byte as zero. So
the tests included having two disks which both had a partition which
was marked as bootable.

Basically, whatever I did the bootable-partition flag made no
difference to the BIOSes choice of which disk to start from. The only
things which made a difference were the 0x55, 0xaa signature and the
value of the first byte of the sector.

The BIOS would execute the sector if its first byte was nonzero
whether there was a bootable partition or not. And even if a partition
was marked bootable, if the first byte was zero the BIOS would not
start it. Note that I tried with the first byte set to one too. Even
though that makes no more sense than being zero the BIOS did start
that sector. So I think I covered all the tests that were needed. I
certainly tried to!

James

[wolfgang kern]

James Harris finally figured: :)

> In another thread we were discussing how the BIOS might select which
> hard disks are eligible to be booted. Some candidate theories about
> the first sector on the disk were
>
> * the first bytes of the sector must have certain low values
> * the partition table needs to have an active partition
>
> Well, I decided to take the plunge and use dd to try the options as
> long as I was very careful! I changed the initial sectors of disks on
> a server which has multiple drives. The findings were surprising and
> are set out below.

> The tests were run on a Phoenix BIOS dated mid 2006. It apparently
> followed these rules.

> If the sector does not end with 0x55, 0xaa
> - the disk does not get booted
> - (and Linux reports: unknown partition table)

> If the sector ends in 0x55, 0xaa:
> If the first byte of the sector is zero
> - the BIOS will *not* boot the sector
> If the first byte is nonzero (from 1 upwards)
> - the BIOS *will* boot the sector

> Significantly, nothing I did to the bootable/active flag made a
> difference. It seems, therefore, that the partition table is
> irrelevant to booting and is not examined. The only checks are of
> exactly three bytes:

> sector ends with 0x55 and 0xaa and begins with a non-zero byte

I may confirm this to be valid for my current machine too.
AMI-BIOS 2009, I checked just a few variations:

1)The BIOS will not boot IF: first byte is zero or first three bytes
contain equal values even it got 55aa at the end and set active-bits.

2)It 'boots from HD', but I better say "load and execute" everything
apart from rule 1) and ends with the 55aa regardless if there are any
partition entries present at all or not (I made it all zero to test).

> Of course, the BIOS can also provide arbitrarily complex options to
> allow the user to choose which of the hard disks it should look at.

> There's nothing we can do about that list and probably nothing we
> would want to do so it is no loss. For the Phoenix BIOS, at least, it
> seems that as it works through the disks that it was told to look at
> by the user it will boot probably the first one that follows the above
> rules.
>
> HTH,
> James

And I hope that this recently rumored BIOS-options for executing
anything else than the first 512 byte from a media remain a fiction
or at least become just (sic?: disablible) options.
__
wolfgang

[James Harris]

On Apr 7, 12:18 pm, "wolfgang kern" <nowh...@never.at> wrote:
> James Harris finally figured:  :)

...

> > Significantly, nothing I did to the bootable/active flag made a
> > difference. It seems, therefore, that the partition table is
> > irrelevant to booting and is not examined. The only checks are of
> > exactly three bytes:
> >  sector ends with 0x55 and 0xaa and begins with a non-zero byte
>
> I may confirm this to be valid for my current machine too.
> AMI-BIOS 2009, I checked just a few variations:
>
> 1)The BIOS will not boot IF: first byte is zero or first three bytes
> contain equal values even it got 55aa at the end and set active-bits.
>
> 2)It 'boots from HD', but I better say "load and execute" everything
> apart from rule 1) and ends with the 55aa regardless if there are any
> partition entries present at all or not (I made it all zero to test).

Great! So that confirms applicability to certain BIOSes from both
Phoenix and AMI. I think we can class dependence on a bootable-
partition flag as Myth Busted. ;-)

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:782b2efb-0991-47fc...@z5g2000yqj.googlegroups.com...

Anyone can write boot sectors that don't have partitions which execute.
Most here have, including me. I've got a half dozen or more of them that I
wrote. But, just whom is going to code a boot sector for an OS without
including the ability to partition the drive? Who would implement just a
single partition today? AIUI, BIOS interrupts are not capable of accessing
the entire capacity of drives anymore, i.e., you need at least two
partitions: BIOS accessible for recovery, and the other. So, no, the
"myth" - this being the first I've heard of a rumored myth in these
regards - is not busted. Partition support is needed to boot any
non-novice, non-toy, non-demonstration, non-trivial, OS. Most of the
problem here, IMO, stems from the mis-use of the term "booting" for
"executing" or "starting".


Rod Pemberton

[wolfgang kern]

Rod Pemberton wrote:

>> James Harris finally figured: :)
> ...
>>>> Significantly, nothing I did to the bootable/active flag made a
>>>> difference. It seems, therefore, that the partition table is
>>>> irrelevant to booting and is not examined. The only checks are of
>>>> exactly three bytes:
>>>> sector ends with 0x55 and 0xaa and begins with a non-zero byte

>>> I may confirm this to be valid for my current machine too.
>>> AMI-BIOS 2009, I checked just a few variations:
>>
>>> 1)The BIOS will not boot IF: first byte is zero or first three bytes
>>> contain equal values even it got 55aa at the end and set active-bits.

>>> 2)It 'boots from HD', but I better say "load and execute" everything
>>> apart from rule 1) and ends with the 55aa regardless if there are any
>>> partition entries present at all or not (I made it all zero to test).

>> Great! So that confirms applicability to certain BIOSes from both
>> Phoenix and AMI. I think we can class dependence on a bootable-
>> partition flag as Myth Busted. ;-)

> Anyone can write boot sectors that don't have partitions which execute.
> Most here have, including me. I've got a half dozen or more of them that
> I
> wrote. But, just whom is going to code a boot sector for an OS without
> including the ability to partition the drive?

Methink all standalone OS can live without partitions.
Partitions are required when one drive must contain several different
FileSystems or if different OS shall be bootable (by boot-mgr! not BIOS).

> Who would implement just a single partition today?

KESYS.SAVE use this since a while.

> AIUI, BIOS interrupts are not capable of accessing
> the entire capacity of drives anymore, i.e., you need at least two
> partitions: BIOS accessible for recovery, and the other.

?? the BIOS INT13/42 struct got a 64-bit wide LBA-field [DS:SI+8]
where only 48 bits can be used today due to LBA48-standards ...
and this mean "144 e15" bytes with still only 512 byte/sector.
So this ~100000 TB could be enough for the next few years.

> So, no, the "myth" - this being the first I've heard of a rumored
> myth in these regards - is not busted.
> Partition support is needed to boot any non-novice, non-toy, non-
> demonstration, non-trivial, OS.

I disagree here, "my OS isn't a toy!" :)

> Most of the problem here, IMO, stems from the mis-use of the term
> "booting" for "executing" or "starting".

Yeah, the misunderstanding may come from M$-land where sector 63
contain the FS-info and the OS-starup code. While sector 0 is the
only thing the BIOS executes, and here the boot-managers hook in.

__
wolfgang

[James Harris]

On Apr 9, 2:12 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

...

> Anyone can write boot sectors that don't have partitions which execute.
> Most here have, including me.  I've got a half dozen or more of them that I
> wrote.

You are ahead of me. I wrote my first one this week.

>  But, just whom is going to code a boot sector for an OS without
> including the ability to partition the drive?

I might be wrong but this sounds like you are mixing up two things
when you talk of "a boot sector for an OS" or you might have just
chosen not to specify. On a hard disk there are at least two types of
bootable sectors. As you know, the first is at the beginning of the
disk, i.e. in LBA 0, and is what the BIOS starts for us. Under a
normal partitioning scheme the second, AIUI at the moment, is the
first sector of a partition. Is that correct? This latter sector is
what ultimately gets started by an MBR. If we designate the bootsector
of the partition the VBR (volume boot record) using the term used in
various articles on Wikipedia the traditional sequence is

BIOS --> MBR --> VBR --> OS

Of the two the VBR sounds more like the your term "boot sector for an
OS" as it starts the OS loading process but I can't see what that has
to do with your comment.

> Who would implement just a
> single partition today?

Do you mean a single partition or a non-partitioned disk? Either way,
someone could do so if he or she wanted to ensure incompatibility with
other systems.

Going back to the MBR....

What the MBR code does once booted is off the original topic. The
first question had to be about what was needed in the first sector of
a hard disk for the BIOS to consider it bootable (executable, if you
like).

An OS developer can control what is on the hard disk including what is
in the bootsector. The same cannot be said of the BIOS settings.
Hence, the boot sector is of interest and worth understanding. If we
don't use either a prebuilt MBR or a prebuilt boot manager the choices
the BIOS makes here determine what is required to give us the initial
control that is needed.

What happens next is another decision and one that is made by the code
in the bootsector. Sure, I'd be interested in partitions at that
point.

> AIUI, BIOS interrupts are not capable of accessing
> the entire capacity of drives anymore, i.e., you need at least two
> partitions: BIOS accessible for recovery, and the other.

True, the traditional BIOS calls cannot access the entire capacity of
all drives any more but you don't necessarily need two partitions. The
key seems to be where a bootable partition starts and where the OS
code is in that partition.

If the MBR tries to load the volume boot record using CHS addressing
the VBR and essential OS code must lie in the first 8Gby (33 bits of
address: 24 in partition table entry and 9 from the size of a sector)
as that is all that a 3-byte CHS value as stored in the partition
table can reach to.

If the MBR tries to use LBA addressing it has a much larger limit but
a limit nonetheless. It is restricted to the first 2Tby (32-bits from
the partition table entry and 9 from the sector size making 41 in
total). So if you had a 3Tby disk and wanted to place the boot
partition near the end then its start address could not be expressed
in a partition table entry.

Both of these methods (CHS and LBA) should be OK, though, to load a
volume boot record that starts at the beginning of the disk - and the
VBR can load an OS from the beginning of the partition - no matter how
big the disk or the partition is.

Of course, the VBR has to use the BIOS to load at least enough of the
OS to include the disk drivers so that/those would need to be within
the range of BIOS calls.

>  So, no, the
> "myth" - this being the first I've heard of a rumored myth in these
> regards - is not busted.

Well, that was an oblique reference to a certain TV show but there was
a "myth" that the BIOS would only start a bootsector which contained a
bootable partition. I've seen a few comments indicating that others
believed that. I did too. This has been shown to be incorrect. BIOS
will start the first sector of a hard disk (using criteria listed at
the beginning of this thread) even if it that sector does not have any
partitions marked as bootable.

>  Partition support is needed to boot any
> non-novice, non-toy, non-demonstration, non-trivial, OS.  Most of the
> problem here, IMO, stems from the mis-use of the term "booting" for
> "executing" or "starting".

Well, that's your opinion. Partitions are just a convention. As we
have established, hard disks do not need to be partitioned in order
for the code in their first sector, to use your preferred terms, to be
executed/started by the BIOS at boot time.

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:4acfa01c-2ccd-4dd4...@v1g2000yqm.googlegroups.com...

> On Apr 9, 2:12 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:

...

> > But, just whom is going to code a boot sector for an OS without
> > including the ability to partition the drive?
>
> I might be wrong but this sounds like you are mixing up two things
> when you talk of "a boot sector for an OS" or you might have just
> chosen not to specify.

No.

> On a hard disk there are at least two types of
> bootable sectors.

There can be one or two sectors (or many more) which get executed. The MBR
and PBR are typical. Due to size constraints, far more sectors are likely.

> As you know, the first is at the beginning of the
> disk, i.e. in LBA 0, and is what the BIOS starts for us.

Yes.

> Under a normal partitioning scheme the second, AIUI at the
> moment, is the first sector of a partition. Is that correct?

Yes.

> This latter sector is what ultimately gets started by an MBR.

Yes.

> If we designate the bootsector of the partition the VBR
> (volume boot record) using the term used in various
> articles on Wikipedia the traditional sequence is
>
> BIOS --> MBR --> VBR --> OS

Yes, that's how booting works. It boots an OS.

I was using PBR (partition boot record) as VBR, whatever the V is for ...

> Of the two the VBR sounds more like the your term
> "boot sector for an OS" as it starts the OS loading process
> but I can't see what that has to do with your comment.

No, I was referring to the MBR when used in the sequence "BIOS --> MBR -->
VBR --> OS" versus "BIOS --> MBR --> OS". The MBR in the sequence "BIOS -->
MBR --> OS" has no partition entries. The MBR in the sequence "BIOS -->
MBR --> VBR --> OS" is (most likely) a multiple partition entry boot sector.
The MBR for that sequence typically has four partition entries. I.e., there
can be four VBR boot sectors each of which could be startable. I was asking
why anyone would implement "BIOS --> MBR --> OS" instead of "BIOS -->
MBR --> VBR --> OS". As stated before, "BIOS --> MBR" is not booting. No
OS is started, although you can run code.

> What the MBR code does once booted is off the original topic. The
> first question had to be about what was needed in the first sector of
> a hard disk for the BIOS to consider it bootable (executable, if you
> like).
>
> An OS developer can control what is on the hard disk including what
> is in the bootsector.

No, whomever has access to the PC while unprotected can control what is in
the bootsector ... If you were to let me use your computers while
unprotected, I can overwrite them, from MS-DOS, from Linux, and probably
from at least a few Windows versions. :) I've not tried with newer
Windows. I seem to recall NTFS was a PIA some years ago though ...

If I can get the machine to boot what I want it to boot by any means (and I
was malicious), your bootsector is gone. The OS developer can only control
what *should be* written there from the OS developer's perspective of
booting their OS. They can't prohibit changes since they don't actually
*own* and *control* the machine.

> The same cannot be said of the BIOS settings.

Yes, I can. Whomever has access to the PC's BIOS while unprotected can
change said settings ... If you were to let me use your computers while
unprotected, I can change them too. :)

> If we don't use either a prebuilt MBR or a prebuilt boot manager
> the choices the BIOS makes here determine what is required to
> give us the initial control that is needed.

"choices the BIOS" ... "choices the BIOS and the user" ...

Don't forget that the user can change the BIOS if not locked, select an
alternate boot device via BBS pop-up if allowed and available, and can
change cabling if the case is not protected via mechanical means or BIOS
case open/closed switch.

> Hence, the boot sector is of interest and worth understanding.

AISI, almost no one is going to code an MBR via happenstance to start with
the few bytes that could be interpreted by the BIOS as blank or unformatted.
So, if you include the 0xAA55 signature for fixed media and valid opcodes at
the sector start, what is the issue? It seems nearly impossible to produce
an MBR that won't execute when attempting to make one that does.

> What happens next is another decision and one that is made
> by the code in the bootsector. Sure, I'd be interested in partitions
> at that point.

Ok.

> > AIUI, BIOS interrupts are not capable of accessing
> > the entire capacity of drives anymore, i.e., you need at least two
> > partitions: BIOS accessible for recovery, and the other.
>
> True, the traditional BIOS calls cannot access the entire capacity of
> all drives any more but you don't necessarily need two partitions. The
> key seems to be where a bootable partition starts and where the OS
> code is in that partition.

True, but usually, the only OS files guaranteed to be written to specific
disk locations are the MBR and PBR and filesystem control structures,
depending on the filesystem. Some filesystems, like MS-DOS with FAT, used
low tracks alot. However, other filesystems, like CBM with CBM-DOS (non-x86
PC), avoided low tracks. Because the low tracks were frequently bad on
removable media, like 5 1/4" floppies, MS-DOS had lots of problems with data
loss and non-bootable disks versus other OSes of that era. 3 1/2" disks
basically "saved" x86 PCs. I.e., while it's likely the OS was installed
"low" since it's the first thing installed to a partition, there is no
guarantee it will be installed in accessible sectors. DOS wrote COMMAND.COM
and IO.SYS low via SYS.com, but AFAIK, Linux and Windows don't write OS code
to specific sectors ... Also, some OSes have utilities which attempt to
access the entire partitions, e.g., DOS' fdisk, Linux fsck, etc. They could
crash or corrupt (track wrap around). Who knows ... IMO, it's better to
terminate the initial partition within the boundaries (and make it a FAT
partition too - lots of DOS utilities.).

> If the MBR tries to load the volume boot record using CHS addressing
> the VBR and essential OS code must lie in the first 8Gby (33 bits of
> address: 24 in partition table entry and 9 from the size of a sector)
> as that is all that a 3-byte CHS value as stored in the partition
> table can reach to.

There is not just the 8GB limit but also the 528MB limit. The Phoenix EDD
specification and one of Hale Landis' webpages might be worth a look.

http://ata-atapi.com/hiwchs.html

> If the MBR tries to use LBA addressing it has a much larger limit but
> a limit nonetheless.

True, AIUI, there is a 28-bit LBA limit and a 48-bit LBA limit.

> It is restricted to the first 2Tby (32-bits from
> the partition table entry and 9 from the sector size
> making 41 in total).

I haven't looked into a partition entry's format, but that doesn't sound
correct to me. AIR, LBA is either 28-bit's (ATA-2 or later) or 48-bit's
(ATA/ATAPI-6 or later) total of 512KB sectors.

> So if you had a 3Tby disk and wanted to place the boot
> partition near the end then its start address could not be
> expressed in a partition table entry.

Yes.

> Both of these methods (CHS and LBA) should be OK, though, to load a
> volume boot record that starts at the beginning of the disk - and the

Well, you've skipped over quite a few other BIOS disk size limitations.
It's probably correct for recent machines.

> VBR can load an OS from the beginning of the partition - no matter how
> big the disk or the partition is.

As long as it's entirely at the beginning ... Disk optimizers, the file
system, file system verifiers, journaling, etc could move just one sector,
and it's all over, if you need to recover.

> Of course, the VBR has to use the BIOS to load at least enough of the
> OS to include the disk drivers so that/those would need to be within
> the range of BIOS calls.

"the VBR" ... "whatever code is executing after the BIOS transfers
execution" ...

You said yourself it could be the MBR. Whatever is executing, could use
BIOS to load alot of sectors from wherever it wants as long as the BIOS
supports it. If the MBR sector just went into a loop and did little else,
you could overload memory ...

At a minimum, you've got from just above 0x7C00 to 512KB that can be loaded
in RM, about 480KB. You've got from 512KB to 640KB on all but the earliest
x86 PCs, another 128KB for 608KB. You've also got 0x400 to 0x7C00, if
you're adventurous. You've got 0x0 to 0x400, if you relocate the IDT.
You've also got various blocks of video RAM from 0xA0000 to 0xE0000, if
you're still adventurous. You've also got from 0x100000 to 0x10FFEF, if you
enable A20. Once your OS is larger than 640KB or 1MB or 1MB+64KB, which is
"huge" for a basic OS, then you can worry about loading your OS above 1MB or
the A20 range.


Rod Pemberton

[James Harris]

On Apr 14, 10:49 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>

wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message

> > On Apr 9, 2:12 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>

...

> > > But, just whom is going to code a boot sector for an OS without
> > > including the ability to partition the drive?

...

>  I was asking
> why anyone would implement "BIOS --> MBR --> OS" instead of "BIOS -->
> MBR --> VBR --> OS".

An OS developer might want his or her OS to be *incompatible* with
existing systems, e.g. so that nothing in it could be manipulated by
standard tools.

>  As stated before, "BIOS --> MBR" is not booting.  No
> OS is started, although you can run code.

As you know I disagree with your restricted view of the meaning of the
word "booting" but I think we have discussed that enough. I now know
what you mean and vice versa.

> > What the MBR code does once booted is off the original topic. The
> > first question had to be about what was needed in the first sector of
> > a hard disk for the BIOS to consider it bootable (executable, if you
> > like).
>
> > An OS developer can control what is on the hard disk including what
> > is in the bootsector.
>
> No, whomever has access to the PC while unprotected can control what is in
> the bootsector ...

...

> > The same cannot be said of the BIOS settings.
>
> Yes, I can.  Whomever has access to the PC's BIOS while unprotected can
> change said settings ...  If you were to let me use your computers while
> unprotected, I can change them too.  :)

That's not what I meant. I was contrasting the impact that as OS
developers we can have on the hard disk with the impact we can have on
the BIOS settings. Unless writing for very specific hardware we can
change what's on a disk but cannot change the BIOS settings.

In other words, we can't change what the user of the PC does but we
can change what we put on a hard disk in order to cope sensibly with
what the user does.

Note, I'm not thinking principally of the user making things awkward
deliberately but of how we can best deal with inadvertent changes made
by the user so as to make that person's life easier. Ways to do that
include not just OS code but also interactivity and documentation.

> > If we don't use either a prebuilt MBR or a prebuilt boot manager
> > the choices the BIOS makes here determine what is required to
> > give us the initial control that is needed.
>
> "choices the BIOS" ... "choices the BIOS and the user" ...

Yes

> Don't forget that the user can change the BIOS if not locked, select an
> alternate boot device via BBS pop-up if allowed and available, and can
> change cabling if the case is not protected via mechanical means or BIOS
> case open/closed switch.

Yes, I'm very aware of this. That's what led to the earlier thread
about which disk a BIOS will boot from.

...

> > > AIUI, BIOS interrupts are not capable of accessing
> > > the entire capacity of drives anymore, i.e., you need at least two
> > > partitions: BIOS accessible for recovery, and the other.
>
> > True, the traditional BIOS calls cannot access the entire capacity of
> > all drives any more but you don't necessarily need two partitions. The
> > key seems to be where a bootable partition starts and where the OS
> > code is in that partition.
>
> True, but usually, the only OS files guaranteed to be written to specific
> disk locations are the MBR and PBR and filesystem control structures,
> depending on the filesystem.  Some filesystems, like MS-DOS with FAT, used
> low tracks alot.  However, other filesystems, like CBM with CBM-DOS (non-x86
> PC), avoided low tracks.  Because the low tracks were frequently bad on
> removable media, like 5 1/4" floppies, MS-DOS had lots of problems with data
> loss and non-bootable disks versus other OSes of that era.  3 1/2" disks
> basically "saved" x86 PCs.  I.e., while it's likely the OS was installed
> "low" since it's the first thing installed to a partition, there is no
> guarantee it will be installed in accessible sectors.  DOS wrote COMMAND.COM
> and IO.SYS low via SYS.com, but AFAIK, Linux and Windows don't write OS code
> to specific sectors ...

You've made lots of points. I'm not sure they are all valid (think of
FAT "System" files, FAT reserved sectors, ext2's 1k boot area and LILO
and GRUB loading their next stages from specific places etc) but *how*
an OS developer achieves loadability is something he or she has to
consider.

> Also, some OSes have utilities which attempt to
> access the entire partitions, e.g., DOS' fdisk, Linux fsck, etc. They could
> crash or corrupt (track wrap around). Who knows ...

Once the OS is running it can provide access to the hard disk for
utilities like fsck. Access via the BIOS is only required to get the
OS running. (More strictly, only to get a read-only disk access
subsystem loaded. Once that is loaded the OS can leave real mode and
access the disk hardware directly.)

> IMO, it's better to
> terminate the initial partition within the boundaries (and make it a FAT
> partition too - lots of DOS utilities.).

Interesting idea, especially about using FAT for this stuff. Main
downside, ISTM, is lack of security but it would be handy for a hobby
OS. And one might lose the use of some Unix utilities. Ummm. Not sure.

...

> > If the MBR tries to use LBA addressing it has a much larger limit but
> > a limit nonetheless.
>
> True, AIUI, there is a 28-bit LBA limit and a 48-bit LBA limit.
>
> > It is restricted to the first 2Tby (32-bits from
> > the partition table entry and 9 from the sector size
> > making 41 in total).
>
> I haven't looked into a partition entry's format, but that doesn't sound
> correct to me.  AIR, LBA is either 28-bit's (ATA-2 or later) or 48-bit's
> (ATA/ATAPI-6 or later) total of 512KB sectors.

Hardware limits? Would 28-bit LBA ever be the only one available on a
disk that is too big for 28-bit LBA? It doesn't sound likely.

Even with 48-bit LBA in hardware the partition table still cannot
express sector numbers bigger than 32-bits.

> > So if you had a 3Tby disk and wanted to place the boot
> > partition near the end then its start address could not be
> > expressed in a partition table entry.
>
> Yes.
>
> > Both of these methods (CHS and LBA) should be OK, though, to load a
> > volume boot record that starts at the beginning of the disk - and the

> > VBR can load an OS from the beginning of the partition - no matter how
> > big the disk or the partition is.
>
> As long as it's entirely at the beginning ...  Disk optimizers, the file
> system, file system verifiers, journaling, etc could move just one sector,
> and it's all over, if you need to recover.

The problem is bigger than just about stopping OS boot code from being
moved beyond the BIOS's reach. If the files which are essential to OS
booting can be moved then the initially loaded code needs some way to
be able to find where the sectors of those files are.

Don't file systems normally have a means of flagging files not to be
moved?

Where would you put your OS startup code so that it is protected from
being moved?

> > Of course, the VBR has to use the BIOS to load at least enough of the
> > OS to include the disk drivers so that/those would need to be within
> > the range of BIOS calls.
>
> "the VBR" ... "whatever code is executing after the BIOS transfers
> execution" ...
>
> You said yourself it could be the MBR.  Whatever is executing, could use
> BIOS to load alot of sectors from wherever it wants as long as the BIOS
> supports it.  If the MBR sector just went into a loop and did little else,
> you could overload memory ...
>
> At a minimum, you've got from just above 0x7C00 to 512KB that can be loaded
> in RM, about 480KB.  You've got from 512KB to 640KB on all but the earliest
> x86 PCs, another 128KB for 608KB.  You've also got 0x400 to 0x7C00, if
> you're adventurous.  You've got 0x0 to 0x400, if you relocate the IDT.
> You've also got various blocks of video RAM from 0xA0000 to 0xE0000, if
> you're still adventurous.  You've also got from 0x100000 to 0x10FFEF, if you
> enable A20.  Once your OS is larger than 640KB or 1MB or 1MB+64KB, which is
> "huge" for a basic OS, then you can worry about loading your OS above 1MB or
> the A20 range.

You lost me. I was talking about where the data comes from (the disk)
not where it goes to!

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:02e7a265-1025-43d5...@f27g2000yqc.googlegroups.com...

> On Apr 14, 10:49 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:

...

> Unless writing for very specific hardware we can
> change what's on a disk but cannot change the BIOS settings.

Oh, sure you can, just indirectly, and limitedly. I see no reason why I
can't have a floppy which "boots" and starts my "C:" fixed drive instead of
my "A:" floppy. I.e., have the OS write *all* boot sectors to default to
starting a specific device, e.g., only IDE port 0x1F0 boots or certain SATA
or USB etc ... So, even if "A:" or "B:" initially "booted" (in the sense
you're using) perhaps because the user selected a different boot device via
BBS menu, only "C:" actually boots. The other device starts, but transfers.
Every time someone inserts a USB stick, "bam!" overwrite the bootsector so
the specific fixed disk starts. This should be similar to writing non-boot
boot sectors that display a message that the media is not bootable. Or,
it's similar to Windows writing serial numbers on all detected removable
media. Or, it's similar to those USB stick virii. Good luck, if that drive
doesn't boot.

> In other words, we can't change what the user of the PC does but we
> can change what we put on a hard disk in order to cope sensibly with
> what the user does.

Uh-oh ...

That sounds very paternalistic to me. I believe in total user control. I
don't want the OS to do *anything* I haven't asked for it to do. That has
led to problems with *every* OS I've ever used. I.e., I don't want the OS
to block me from being able to write my choice of boot sector, unless it is
a high-security OS. Even for high-security OS, one still occasionally has
to install, reinstall, fix bad boot sectors, or change the OS on that PC
when repurposed. I.e., if future OSes have built in AI and can determine
that I always read my horoscopes at a certain time of the day, I don't want
the OS to attempt to open my browser and start those webpages automatically.
If the OS is going to do something "smart" for me, it needs to be so
unintrusive and subtle that I *never*, *ever* notice it. Or, I'll rip it
right the freak out of the OS, delete it, modify binaries, whatever it takes
...

> [...] I'm [...] thinking [...]

> of how we can best deal with inadvertent changes made
> by the user so as to make that person's life easier.

What qualifies as inadvertent?

Let's take WinXP. Some years back on a PC I had access to, the user's
Norton Antivirus detected a system file that it believed matched a virus
infection. As a system file, WinXP protected the file from deletion. I.e.,
it prohibited "inadvertent" user deletion of a system file. Norton couldn't
delete it. The user account couldn't delete it. The admin account could
delete it. However, upon reboot, WinXP would restore the system file from a
backup directory - also a supposedly infected version of the file. The OS
would not restart without restoring the file. Catch-22. The proper course
of action would be 1) to allow file deletion, to not boot if the file was
needing for booting, or 2) to allow file deletion, and require the user to
replace the file before shutdown, or 3) to allow file deletion, allow the
user to select an alternate file for replacement, replace upon bootup. IMO,
it's not up to the OS to decide whether or not something is "inadvertent".
User's, even really dumb ones, are frequently far smarter than the simple
"intellect" very smart people decided to code into the OS.

> FAT "System" files

Written low - mentioned that.

> FAT reserved sectors

Written low - mentioned that.

> ext2's 1k boot area

...

> LILO and GRUB loading their next
> stages from specific places etc)

...

Still, none of that is the OS. It's the bootloader and startup code. The
OS image or executable is going to be stored in the partition somewhere.
It's sectors are not locked are not forced to be low numbered. It is likely
written to the partition first. So, initially, it's sectors are low
numbered and BIOS accessible. However, it's sectors can be relocated.
I.e., not stored within BIOS loadable range.

> Once the OS is running it can provide access to the hard
> disk for utilities like fsck.

True.

> Access via the BIOS is only required to get the
> OS running.

True.

But once the OS is running, disk utilities can relocate sectors of the OS to
where the BIOS can't access it. E.g., you installed your OS. You booted it.
You ran fsck. It relocated a sector beyond the BIOS supported sector range.
You attempt to reboot. Crash or lockup or ... That's the point of not
having an initial partition too large.

> (More strictly, only to get a read-only disk access
> subsystem loaded. Once that is loaded the OS can
> leave real mode and access the disk hardware directly.)

You still generally need a bootloader and/or minimal OS to control and
operate the "disk access subsystem". It doesn't just run on it's own.

> If the files which are essential to OS booting can be moved
> then the initially loaded code needs some way to
> be able to find where the sectors of those files are.

Yes. That's called a directory. The startup code which has filesystem
support finds the partition's directory and loads files from the partition
using the file allocation tables or file's sector links, depending alot
on the implementation of the filesystem.

> Don't file systems normally have a means of flagging files
> not to be moved?

They could, but that's not so for the ones I'm familiar with
(or still remember) ...

> Where would you put your OS startup code so that it is
> protected from being moved?

If something is located outside the range occupied by all partitions, then
it's not movable except via special utilities. The filesystem (re)moves
stuff, e.g., for copy, delete, within a partition. If you want the OS image
to be protected, I'd think it'd be located outside the partitions too.
I.e., the utility directly writes the OS image to specific sectors. The
partitions can't occupy those sectors. There is a problem if they can. If
really paranoid, you'd put it both places and verify it hasn't changed, or
compare hash values of the image, etc, and the bootsector(s) too.

What do you mean by "OS startup code" exactly? MBR? VBR? Boot loader?
Filesystem structures like allocation tables? The OS image? All of it?
Some of it?


Rod Pemberton

[James Harris]

On Apr 15, 5:49 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

...

> > Don't file systems normally have a means of flagging files
> > not to be moved?
>
> They could, but that's not so for the ones I'm familiar with
> (or still remember) ...

IIRC Windows disk defrag left some files in place - maybe those which
had the System attribute bit set.

> > Where would you put your OS startup code so that it is
> > protected from being moved?
>
> If something is located outside the range occupied by all partitions, then
> it's not movable except via special utilities.  The filesystem (re)moves
> stuff, e.g., for copy, delete, within a partition.  If you want the OS image
> to be protected, I'd think it'd be located outside the partitions too.

Maybe. Problem is that for disks which have space outside partitions
there is no guarantee that something else won't overwrite anything put
there.

...

> What do you mean by "OS startup code" exactly?  MBR? VBR? Boot loader?
> Filesystem structures like allocation tables? The OS image?  All of it?
> Some of it?

To me it's the code which gets the OS to a state of not needing the
BIOS. If the VBR were big enough that would be ideal as all such code
could be stored therein and would not be movable. But the VBR may be
too small to contain code to walk a complex filesystem.

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:2a7bc44e-9892-42e6...@i18g2000vbx.googlegroups.com...

> On Apr 15, 5:49 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
...

> > > Where would you put your OS startup code so that it is
> > > protected from being moved?
>
> > If something is located outside the range occupied by all partitions,
> > then it's not movable except via special utilities. The filesystem
> > (re)moves stuff, e.g., for copy, delete, within a partition. If you
> > want the OS image to be protected, I'd think it'd be located
> > outside the partitions too.
>
> Maybe. Problem is that for disks which have space outside partitions
> there is no guarantee that something else won't overwrite anything put
> there.

Are you talking about some type of sector lock-out?

I can't imagine anything like that being implemented on standard hardware.
It might be on high-end hardware encrypted or secure drives. E.g., perhaps,
that's an iffy perhaps - a guess really, a disk region is password protected
at the hardware level. You'd need to do a bit of research on those advanced
drives.

A regular drive that is encrypted wouldn't prohibit "something else" from
overwriting, but it could prevent a code injection or boot sector
replacement attack. I.e., the encrypted drive would (most likely - still
guessing) attempt to unencrypt the malicious code, which was unlikely to
have been properly encrypted in the first place. So, if someone attempts to
modify system files, the drive is trashed, basically. Or, the injected code
would fail a hash value or checksum test. Of course, whether that's
entirely true or not, depends on who is attempting to bypass your
encryption.

For normal, cheap hardware, the most you'll likely have is a write protect
tab. None of my HDs are lockable by physical switch, AFAIK. It's possible
one of those 2-pin jumpers "locked" them. Some USB sticks are lockable by
physical switch. My USD hard drive and my SSD drive is not lockable by
physical switch.

So, maybe USB stick for your "OS startup code", which then boots off another
drive with larger capacity. Pulling the USB stick out would effective
hamper
booting for many. Although, a CD-R or DVD-R would probably work better:
permanent, easily broken in hand, etc. If it's a custom OS with encrypted
drives,
the device/media with "OS startup code" acts like a secure "dongle". If
you lose it or you toss it, big problems for whomever wants access.

> If the VBR were big enough that would be ideal as all such code
> could be stored therein and would not be movable. But the VBR may be
> too small to contain code to walk a complex filesystem.

It's a Hugi compo challenge which needs compression ... :)


Rod Pemberton

[James Harris]

On Apr 16, 1:16 am, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:

...

> Are you talking about some type of sector lock-out?

Whatever that means, No! .... This should probably be a separate
thread.

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:2a7bc44e-9892-42e6...@i18g2000vbx.googlegroups.com...

> On Apr 15, 5:49 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
...

> Problem is that for disks which have space outside partitions
> there is no guarantee that something else won't overwrite
> anything put there.

How do you intend to fix that?


Rod Pemberton

[James Harris]

On Apr 16, 8:44 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
> "James Harris" <james.harri...@gmail.com> wrote in message

I don't know. I was hoping you had some ideas.... It was your
suggestion, wasn't it!

No need to reply unless you want to. I think this topic needs a
separate thread but there are other things to discuss first as they
may provide an answer.

James

[Rod Pemberton]

"James Harris" <james.h...@gmail.com> wrote in message

news:919c0f17-68d7-4aa6...@v1g2000yqm.googlegroups.com...

> On Apr 16, 8:44 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
> > "James Harris" <james.harri...@gmail.com> wrote in message
> news:2a7bc44e-9892-42e6...@i18g2000vbx.googlegroups.com...
> > > On Apr 15, 5:49 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> > > wrote:
...

> > > Problem is that for disks which have space outside partitions
> > > there is no guarantee that something else won't overwrite
> > > anything put there.
> >
> > How do you intend to fix that?
> >
> I don't know. I was hoping you had some ideas...
>

If there is no method to block writing to a track via the hard disk, then
all solutions are purely software based in the same sense as attempting to
control boot order. I.e., the special OS utilities to access areas outside
partitions such as the MBR and the filesystem will need to be coded to
either not write there, or only write there for specific situations.

Once the OS has started, one could block use of RM so that the BIOS can't be
used to write to the disk, i.e., use protected mode with privilege levels.
The goal there being to force the user to use the OS' device I/O functions,
which are controlled by the OS. E.g., if the OS uses the protections of
protected mode, i.e., protection rings, controlled port access, etc then the
user can't write to devices directly via ports and they can't execute
special OS related instructions due to lack of privilege resulting in them
taking control of the machine. Without the ability to do those three things
(no port privilege, no instruction privilege, no routines), the user can't
install their own "device drivers" or code to access devices. However, if
security is weak or breachable somewhere, they could. They only need to be
able to save text to write x86 code, i.e., those x86 instructions which
correspond to ASCII. If they can execute code, escalate privilege, and
access ports, then they could write their own "device drivers".


The ATA/ATAPI spec.'s have these commands which seem to be security related:

de door media lock (ATA/ATAPI 1 thru 7)
df door media unlock (ATA/ATAPI 1 thru 7)

f1 security set password (ATA/ATAPI 3 thru 7)
f2 security unlock (ATA/ATAPI 3 thru 7)
f3 security erase prepare (ATA/ATAPI 3 thru 7)
f4 security erase unit (ATA/ATAPI 3 thru 7)
f5 security frees lock (ATA/ATAPI 3 thru 7)
f6 security disable password (ATA/ATAPI 4 thru 7)

f9 01 set max password (ATA/ATAPI 4 thru 7)
f9 02 set max lock (ATA/ATAPI 4 thru 7)
f9 03 set max unlock (ATA/ATAPI 4 thru 7)

That's from my notes. That's probably my paraphrase wording ... My notes
mention "host protected area" and "security mode" in regards to most of
those. Do most drives support those? Unlikely, IMO.


Rod Pemberton

[James Harris]

On Apr 17, 11:08 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>

wrote:

...

> > > > Problem is that for disks which have space outside partitions
> > > > there is no guarantee that something else won't overwrite
> > > > anything put there.
>
> > > How do you intend to fix that?
>
> > I don't know. I was hoping you had some ideas...
>
> If there is no method to block writing to a track via the hard disk, then
> all solutions are purely software based in the same sense as attempting to
> control boot order. I.e., the special OS utilities to access areas outside
> partitions such as the MBR and the filesystem will need to be coded to
> either not write there, or only write there for specific situations.
>
> Once the OS has started,

...

Good comments (snipped) and yes, once the OS has started it has
control but I wasn't so much thinking of malicious code. After all, a
machine can be booted from a floppy or CD etc and run code that can be
harmful and overwrite stuff on the hard disk.

I was thinking more that there is no allocation system for any space
which is not in a partition. Therefore if we put something *we* want
there another program could later put *its* code or data in those
spaces overwriting our stuff. It was your comment that I was
responding to where you seemed to suggest storing boot code/data
outside a partition:

RP> If something is located outside the range occupied by all
partitions, then
RP> it's not movable except via special utilities. The filesystem
(re)moves
RP> stuff, e.g., for copy, delete, within a partition. If you want
the OS image
RP> to be protected, I'd think it'd be located outside the partitions
too.

You have a point. Stuff in any non-partitioned space may not be
movable. However, other programs may overwrite it. They simply don't
know that the user has something there that should be kept.

There's probably no perfect solution.

James