Re: using segmentation in the kernel

["Jonathan M. McCune" <jonmccune@cmu.edu>]

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

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.
>
> Cheers,
> Dick Johnson

Hello,

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.

Thanks,
-Jon

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