Re: using segmentation in the kernel

From: Jonathan M. McCune
Date: Wed Oct 12 2005 - 18:57:34 EST

Alan Cox wrote:

On Mer, 2005-10-12 at 11:05 +0200, Arjan van de Ven wrote:

separate modules so that they will not affect kernel and more...

and I don't believe this one yota. THe only way to do this is to run
modules in ring 1, at which point you are in deep shit anyway.

Not neccessarily. Its how Xen works on x86-32 for example. It keeps
itself protected from the entire Linux instance by using segmentation on
32bit processors (not 64bit however as x86-64 has no segments in 64bit)

Doing that without major work on the kernel itself would be hard, and
you'd need to isolate out things like page table updates and verify them
whenever modules wanted to touch such stuff


linux-os (Dick Johnson) wrote:

On the ix86 you have a problem. Let's say that you write some
code from scratch, that runs the CPU in 32-bit linear address-mode
without paging. Then you want to activate paging. To activate
paging, you MUST have provided some code and some data-space for
your descriptors, where there is a 1:1 mapping between virtual
and bus addresses. If you don't do this, at the instant you
change to paging mode, you crash. The CPU fetches garbage.

This is why the first few megabytes of Linux are unity-mapped.
You will always need to run the kernel out of an area where
a portion of that "segment" is unity-mapped. That segment
is where the descriptors for addressing, paging, and interrupts
must reside.

If you truly wanted to run the kernel from 3-4 GB as you state,
you must have RAM there, i.e., some physical stuff so that
a 1:1 mapping could be implemented. The 3-4 GB region is
where a lot of PCI addressing occurs on 32-bit machines and,
in fact, there are some "do-not-touch" addresses in that
region as well.

Remember that the kernel runs in virtual address mode, but
the descriptors that specify that mode need to be in physical
memory, addressed at the same offset. You can experiment
by making a module that attempts to turn off paging and
then turn it back on. The kernel will crash instantly.
However, if you write some code somewhere in low address-
space where the startup code already exists, that turns
off paging, then turns it back on; and your module code
calls this other code, the machine will work fine. You
need the interrupts off when you play.

So, basically you can't do what you want with any OS that
uses ix86 type CPUs. The question is; "What was it that
you really wanted to do?". What you gave us was the
"implementation details". What I want to know is what
you intend to accomplish. The ix86 architecture lends itself
to a lot of interesting things so if I knew your intentions
I might be able to help.

Dick Johnson


Thanks for all the responses. The project we are working on does
involve the use of Xen, so we have the advantage of Xen's taking care
of the bootstrapping hassles with "unity mapping" parts of the kernel.
To put it another way, the architecture we are really interested in is
xen-i386. We are curious about the implications of restricting the
kernel's code and data segments such that the kernel cannot read/write
user space directly. We want to set the base address of the Kernel
segment descriptors to 3GB and the limit to 1GB-64MB ( Xen uses the
top 64 MB). We were just wondering if the best way to achieve this
would be to change the kernel linker script and the segment base
addresses appropriately. Any insight into whether this would work at
all or what would work and how to debug something like this would be
greatly appreciated.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature