Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Russ Cox]

> (Indeed, perhaps the MD5 hashes should be on the download pages.)

there's no md5 hash for the floppy
image because each floppy has a different
plan9.ini depending on what hardware you
described.

as for your actual problem, somehow the lock
has been acquired and the processor is trying to
acquire it again.

the most likely happening is that somehow our
cli/sti code isn't quite working under bochs.

how hard is bochs to install?

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Steven Taschuk]

Quoth Russ Cox:
> > (Indeed, perhaps the MD5 hashes should be on the download pages.)
>
> there's no md5 hash for the floppy
> image because each floppy has a different
> plan9.ini depending on what hardware you
> described.

Ah.  Yes, I'd forgotten that.

Would it be prohibitively time-consuming to calculate the hash on
the fly after the "make download diskette" button is invoked,
i.e., at the same time as the diskette image is created?  Then the
hash could appear on the same page as the actual floppy image
download link.

(The hash in my previous post was, as it happens, for the vanilla
all-defaults floppy.)

[...]
> how hard is bochs to install?

I found it painless.  In GNU and facsimile environments at least,
it goes something like this:
  1. ./configure, make, make install
  2. Install one font.
  3. Configure a machine to be emulated.
That's it.  On my machine it compiled out of the box, no hacking
or weird ./configure --options required, and I didn't need to
learn any black magic to tweak the sample bochsrc file into the
form I desired.

See <http://bochs.sourceforge.net/>.

--
Steven Taschuk           | I will be a square age
staschuk@telusplanet.net | in a square year.
                         |

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Dan Cross]

> For my next trick... I wonder whether the MD5 algorithm is such
> that the hash for the concatenation of two blocks of bits can be
> determined quickly from the hashes for the two blocks.

Good God, I hope not.  MD5 shouldn't be a homomorphism.

> Then, you
> see, you could have the hash(es) for the invariant part(s) of the
> disk image lying around, and combine it (them) on the fly with the
> hash for the user's individual plan9.ini.

You could hash the hashes of the two bits, which would be
computationally cheap (relatively speaking).

	- Dan C.

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Boyd Roberts]

Steven Taschuk wrote:

>For my next trick... I wonder whether the MD5 algorithm is such
>that the hash for the concatenation of two blocks of bits can be
>determined quickly from the hashes for the two blocks.
>
I would say that the treatment of the last block would negate this;
it is 'padded' and then hashed.  I suppose you could keep the hashes
of the penultimate blocks and then compute the last blocks' hashes,
but this smacks of a lot of chicanery for not much gain.

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Steven Taschuk]

Quoth Russ Cox:
 [quoting me]
> > Would it be prohibitively time-consuming to calculate the hash on
> > the fly after the "make download diskette" button is invoked,
> > i.e., at the same time as the diskette image is created?  [...]
>
> it wouldn't be time-consuming for the computer, but it
> would be time-consuming for us.  that's not the way the
> download works.  it would require creating the floppy image,
> and we don't actually do that to generate the floppy
> image download link.  we just generate and save the plan9.ini,
> which is inserted as we send you the disk image.

Well, that makes sense.

For my next trick... I wonder whether the MD5 algorithm is such
that the hash for the concatenation of two blocks of bits can be
determined quickly from the hashes for the two blocks.  Then, you
see, you could have the hash(es) for the invariant part(s) of the
disk image lying around, and combine it (them) on the fly with the
hash for the user's individual plan9.ini.

Not that the problem is really that important, sadly.

--
Steven Taschuk           | "Renner was competent.  Renner was also a
staschuk@telusplanet.net |  smartass; but that was a good bargain."
                         |  (_The Mote in God's Eye_, Niven & Pournelle)

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Steven Taschuk]

Quoth Russ Cox:
> i think they're more worried about the tcp bringing
> down the wrong data.  [...]

Indeed.

But it was really just an errant notion I had; an unlikely but
conceivable problem that would confound further troubleshooting
and so was worth spending two minutes to check.

Of course, it turns out to take more than two minutes, since MD5
sums are not available.

On another matter: I've never been referred to as a "they" before.
I kind of like it.

--
Steven Taschuk           | Aral: "Confusion to the enemy, boy."
staschuk@telusplanet.net | Mark: "Turn-about is fair play, sir."
                         | (_Mirror Dance_, Lois McMaster Bujold)

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Geoff Collyer]

Alas, Thomas didn't do a literature search, we discussed these ctype
problems long ago, in

%T Can't Happen or /* NOTREACHED */ or Real Programs Dump Core
%K programming style robustness reliability
%A Ian Darwin
%A Geoff Collyer
%J Proc. Winter Usenix Conf. Dallas 1985
%P 136-151
%D January 1985

:-)

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Russ Cox]

> You forgot to mention that Plan 9 is unhackable and therefore the
> md5 hash is not really necessary ;)

i think they're more worried about the tcp bringing
down the wrong data.  thomasbsd is the only
unhackable system.

Date:         Sun, 1 Apr 2001 00:08:50 +0200
From: Thomas Lopatic <thomas@LOPATIC.DE>
Subject:      ThomasBSD Security Advisory #1
To: BUGTRAQ@SECURITYFOCUS.COM

                   *** ThomasBSD Security Advisory #1 ***

                               Thomas Lopatic

                              April 1st, 2001


Introduction
------------

Having just found a serious security problem in the current release of
a core Internet service, I have decided to start working on my own
highly secure distribution of BSD, which will be called "ThomasBSD"
for obvious reasons.

Features of ThomasBSD
---------------------

ThomasBSD is based on OpenBSD, thus it is OpenBSD PLUS MORE,
mathematically making it (NetBSD PLUS MORE) PLUS MORE.

The epoch of ThomasBSD will be moved back from January 1st, 1970 to
January 1st, 1960. Whenever a security problem is found and fixed in
OpenBSD, this little shift will enable me to also correct the issue in
ThomasBSD and then send mail to security-related mailing lists stating
that "this was fixed in ThomasBSD about ten years ago."

In addition, ThomasBSD will, in a slightly different application of
the epoch shift, always be able to claim "Ten years without any local
or remote holes in any install, i.e. in the default install PLUS
MORE."

My original plan was to only provide binary releases of ThomasBSD, so
that I would not have to go through the efforts of hiding
security-critical changes in the CVS tree by inventing harmless
comments.

Still, as binaries can be reverse engineered, ThomasBSD releases will
only consist of the MD5 sums of the binaries. However, people actively
contributing to ThomasBSD will be able to obtain MD5 sums of the
source code.

This will ensure that no other operating system can copy any fixes
from ThomasBSD, and thus provide ThomasBSD with a USP, i.e. a unique
security position.

Obtaining ThomasBSD
-------------------

Binary releases will be regularly mailed to bugtraq. ThomasBSD 1.0 is

                  8e507e385887e487d3b6c600d09d1f23.

The mentioned security problem
------------------------------

This advisory will be the only time that I provide information on a
problem fixed in ThomasBSD that exceeds an MD5 sum of the diffs.

The problem is related to using isdigit() on user-supplied signed
characters without using isascii() first or type-casting the signed
character to an unsigned character or doing something similar.

Thus, the integer supplied as an argument to isdigit() may be
negative. If it is negative, the isdigit() function - depending on the
operating system's implementation of libc - potentially performs
look-ups outside its look-up table, since the provided integer is used
as an index for the look-ups.

It has to be noted that some implementations of libc use a construct
along the lines of

[...]

unsigned short table[256 + 128];
unsigned short *base;

[...]

    base = table + 128;

    if (base[input] & ISDIGIT_MASK)
        return TRUE;

    return FALSE;

[...]

together with a table in which table[x] == table[x + 256] to be
tolerant to sloppy coding and return the same values for the inputs of
-128 and 128, -127 and 129, -126 and 130, etc.

However, in vulnerable libraries isdigit() may return TRUE for at
least some negative inputs. As a further hint, consider the following
code snippet.

[...]

int i, v;
char in[MAX_INPUT_SIZE];

[...]

    for (i = v = 0; in[i] && isdigit(in[i]); i++)
        v = v * 10 + (in[i] - '0');

[...]

Also consider the fact that if the variable v was used as an index in
the program that this snippet belongs to, a programmer would typically
rely on v - having been calculated in the way described - being
non-negative and only validate the upper bound before using the index,
i.e. compare v to the number of elements in the array, as in

[...]

unsigned int array[ARRAY_SIZE];

[...]

    if (v >= ARRAY_SIZE)
        return -1;

    array[v] = [...]

The rest of the problem is left as an exercise to the reader. (Hint:
What happens if v is negative?)

Since vulnerabilities based on the described invalid use of the
isXXX() class of functions have up to now not been documented, I claim
the right of assigning this class of security problems a name, the
name of my choice being "giraffes". This will facilitate communication
among security experts as in

             "Cool, I've found a new giraffe in OpenBSD!"

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Russ Cox]

> Would it be prohibitively time-consuming to calculate the hash on
> the fly after the "make download diskette" button is invoked,
> i.e., at the same time as the diskette image is created?  Then the
> hash could appear on the same page as the actual floppy image
> download link.

it wouldn't be time-consuming for the computer, but it
would be time-consuming for us.  that's not the way the
download works.  it would require creating the floppy image,
and we don't actually do that to generate the floppy
image download link.  we just generate and save the plan9.ini,
which is inserted as we send you the disk image.

as you might imagine, it's a lot less disk space
to have just a different plan9.ini for each session
than a different image.

also, even the "default" disk is different for each
downloader, since it contains the installurl in plan9.ini,
which has your very own random session cookie.

Re: [9fans] OS install floppy hangs during boot on Bochs 1.4.1

[andrey mirtchovski]

You forgot to mention that Plan 9 is unhackable and therefore the
md5 hash is not really necessary ;)

[9fans] OS install floppy hangs during boot on Bochs 1.4.1

[Steven Taschuk]

I find that the boot floppy hangs fairly early on when used in a
Bochs emulated PC.  Details below; any suggestions would be
appreciated.

I have consulted the Wiki page on installation troubleshooting and
searched the comp.os.plan9 archives at Google; the topic of
running in Bochs seems to come up in the newsgroup now and then
(usually with such phrases as "not working"), but I find nothing
about Bochs more recent than late 2001, and nothing concerning
this specific hanging problem, in emulators or otherwise.  (Note
also that this problem might well be due to some newbie error(s)
on my part.)

The underlying machine is an x86 Linux box with kernel 2.4.17 and
glibc 2.2.4.  The Linux system was built by hand, that is, not
installed from a distribution such as RedHat, Slackware, etc..
The emulator is Bochs 1.4.1; the behaviour described below occurs
with both VGA BIOSes shipped with that version.

Booting the emulated machine from 9disk.flp looks like this:

------------------------------8<------------------------------
PBS...Plan 9 from Bell Labs
using fd0!dos!plan9.ini
.dev A0 port 1F0 config 0040 capabilities 0000 mwdma 0000
found 9pcflop.gz
.gz.............................................................................
.............................................................................124
0730 => 711025+1093800+56912=1861737
entry: 80100020
cpu0: 2MHz GenuineIntel P5 (cpuid: AX 0x0513 DX 0x0011)
4575 free pages, 18300K bytes, 96700K swap
ilock:: ad de ad de 06 00 00 00 3b 89 18 80 d8 77 2c 80 01 00 00 00 70 e5 00 80
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
------------------------------8<------------------------------

At this point the emulated machine seems to hang.  Sometimes it
produces a second ilock: blurb such as the above; sometimes it
produces the character 'p'.  (Never both, but sometimes neither.)

Bochs is, of course, quite slow, and sometimes seems to hang when
in fact it's just taking its sweet time to do something.  For
certainty, I let it sit at the point shown above for about three
hours; no further output appeared in that time.

It may be that the floppy image I have was damaged during
download; perhaps someone could check that their copy has MD5 hash
    575bb7ddd7403718fed4e3807235d4ca  9disk.flp
(Indeed, perhaps the MD5 hashes should be on the download pages.)
However, I think such a problem is improbable: I have tested the
image by writing it to a floppy and booting the real machine
therewith; in that scenario, it proceeds happily past the point of
failure above.  (It says "kfs...", for example.)  I conclude that
the floppy image is probably fine, and that something strange is
happening in the Bochs environment specifically.

Booting the emulated machine from plan9.iso is also unsuccessful,
in what I assume to be yet another unrelated problem:

------------------------------8<------------------------------
PBS...Plan 9 from Bell Labs
dev A0 port 1F0 config 0040 capabilities 0000 mwdma 0000
Boot devices: fd0 fd1
boot from:
------------------------------8<------------------------------

The emulated CD-ROM drive is the slave on the primary controller,
so I try...

------------------------------8<------------------------------
boot from: sdC1!cdboot!plan9.ini
boot from:
------------------------------8<------------------------------

... with, as you see, no luck (but also with no helpful error
message <shakes fist>).  Presumably the fact that sdC1 is not
listed as one of the possible boot devices is significant.

Incidentally, I do not find in the installation documentation any
description of what to type at a "boot from:" prompt.  Is my guess
above correct?  Is this documented anywhere else?

--
Steven Taschuk           | Kinsley's Law: "Every public
staschuk@telusplanet.net |  frenzy produces legislation
                         |  purporting to address it."