Subject: Re: compartmentalization of kernel memory
To: David Laight <email@example.com>
From: John Gordon <firstname.lastname@example.org>
Date: 04/06/2003 00:03:48
> Doesn't the SA1100 (at least) let you move the table to an alternate
> (fixed and not particularly useful) address?
That it may, but I was designing solutions that would work across all the
family members, not just one chip (and esp. not that one - I'm only thankful
that Intel killed the chip before all the brutus boards died ;-)
I don't believe that the core spec. supports moving of the vectors in the
virtual space. It does support moving them in physical memory since they are
accessed with the MMU on. That's essential on the SA devices since their
physical RAM is located up high in the physical address space to aid in WinCE
compatibility - I suspect that the vector shifting feature is there for a
similar reason, along with the special process ID feature in the MMU that means
WinCE doesn't need to know about virtually indexed caches.
> Could the 16 protection bits (forgotten what they are called) be used??
The domain access control bits; unfortunately not because the occurrence of an
exception does not change the current domain, so the processor would still be
unable to access the vectors when an exception occurred. The PPC architecture
solves this problem by automatically disabling the MMU when an exception
occurs. It is a pain to deal with at times from an OS perspective, but it does
allow for no-access vectors in normal operation, so it's not all bad ;-)
> I remember moving the vector table from 0 on a 286 (real mode) system.
> At least random overwrites didn't splat on the illegal instruction
> vector - also let us use a logic analiser to trap the accesses.
Having the vectors protected from bad pointer ops is always good. Even the
read-only mode we ended up with for ARM is a big improvement on unprotected -
at least we knew nobody would corrupt them. It just meant that kernel code
would be able to dereference null pointers for read ops and not be detected.
Since all the other architectures we ran on supported no-access on page zero,
the code at risk was the ARM-specific stuff, and there wasn't much of that.
Rate Corporate America at http://exec-ratings.bluedonkey.org
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more