Fwd: Re: zlib-1.1.4 out - security fix

Bill Maltby LFS Related lfsbill at wlmlx1.wlmcs.com
Wed Mar 13 05:47:47 PST 2002


Ian,

I'm starting to feel guilt, so after this, I'm taking my part of this
thread to the Local beer hall.


On Wed, 13 Mar 2002, Ian Molton wrote:

> <snip>

> 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. 

Yes. That was akin to "craftsmanship" and "elegance". You don't see much
of either anymore. Too bad. :-(

><snip>

> A few months. I've been hitting heisenbugs.

Well, not unusual. Half the time I know where I'm at but not which way I'm
headed. The rest of the time, that's inverted. And when I try figure out
both at once, I seem to get Alzheimer's.

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

Well, _you_ better not get Alzheimer's! ;-)

> 
> 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'.

Speaking of which, how's the hardware holding up. Anything besides the IDE
drives occasionally need repair? What do you do then?

><snip>
 
> 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 ;-)

Same in real life - parents get worn down, children just keep running us
ragged.

> > 
> > 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).
> 
> <snip>

Bill Maltby
billm at wlmcs.com

-- 
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