Fwd: Re: zlib-1.1.4 out - security fix

Ian Molton spyro at armlinux.org
Tue Mar 12 16:32:25 PST 2002


On a sunny Tue, 12 Mar 2002 18:26:14 -0500 (EST) Bill Maltby LFS Related
gathered a sheaf of electrons and etched in their motions the following
immortal words:

> And _knobs_ and _switches_. We could stop dead in their tracks,
> single step, go over and spin a tape manually past a bad spot and
> start that bugger up again.

hehe ;-)
 
> 26 bits? That's mainframe class in the old days. Burroughs, Honeywell and
> several others had "mainframes" that had similar path widths.

The CPU is was actually a 32 bit device.

The PC uses 8 bits to store the flags and processor mode, so you had:

NZCVFI [24 bits PC] [2 bits CPU mode]

the CPU mode bits get put on the address bus too, giving a 64 bit address
range, which, with the standard MEMC controller is split up so you have
32MB virtual addrerss space in user mode, 16MB physical address space on
top of that, some IO above that, and then writing to the space above that
programs the MMU mappings, and reading from it reads from up to 12MB of ROM
address space.

Its an interesting arch, as the memory controller has no connections to the
data bus - its programmed entirely by dummy writes to the ROM space.

likewise, the video chip from the system has no address bus connections, as
the video dma and address selection is driven by the memory controller.

all this was done to reduce the pin count on the packaging, to lower cost
of the chipset.

the whole thing is completely asynchronous too - the CPU can run at a
different speed from MEMC and the video controller.

Its cool ;-)

I just love the way the engineers have crammed what they can into every
available bit, not like todays bloatware. 
> How long have you working at that "port". It sounds like an impressive
> amount of dedication is needed. Fairly lonely endeavor?

A few months. I've been hitting heisenbugs.

Its very lonely. as far as I know I am the ONLY person attempting to run
linux on this machine.

It /used/ to have a working port, around 2.0.xx but Im working on 2.4 and a
LOT of the code has 'rotted'.

I can run non-forking programs well enough - I have one that scanf(%s) a
line of input and then printfs it back to me, a couple of recursive
function tests (tests stack). 
> > It will start, init a framebuffer, and even load and run simple
> > programs. however a call to fork() will kill things in short order -
> > the child runs, but the parent does not ;-)
> 
> What's the prognosis, Doc? Think you'll find the cure eventaully?

As long as the poor machine doesnt die before I do. I have to power cycle
it to get the netcard to reset, and the harddisc isnt loving that. (its IDE
though, so at least thats not a porblem).

> > you can treat all 16 regs pretty much the same, including doing math on
> > the PC :)
> 
> Oh yes! That's what a _real_ computer is - a machine that enables, not
> disables the programmers.

Yep. simple implementation too - none of this X86 'bolt on a new insn'
crap. just a few (14, IIRC) instructions that let you do ANYTHING. 
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-security' in the subject header of the message



More information about the lfs-security mailing list