[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

last one, kernel-switching, microkernel, dynamically loading kernels.



On 2002.12.30 10:57 Russell Coker wrote:
On Mon, 30 Dec 2002 00:36, Francis Whittle wrote:
> Dunno anything about TCPA, sorry.

I recommend that you read about it, it does some of the things that
you seem
interested in.

I'm not really interested in this stuff, really...
I just had a brief flash of possible future.


> > I wasn't aware of any crypto support in mainframes.  Do you have
any
> > references as to what the S/390 family supports in this regard?
>
> I was meaning in terms of channels bypassing processors.  Mainframe
> channels don't neccesarily need to use a processor, or even
classical
> memory sometimes, they can do software<>channel<>device.

Like bus-mastering PCI cards.  You can have two PCI cards talk to each
other
without involving main memory or CPU.

Sort of.  Well, yeah, like that.


> You have a bootloader, a pre-vm that defines a minimal threading
set, a
> linux security vm (low priority) a linux kernel vm, a security
> interface to comminucate with the authentication system.  These are
all
> in software; like so (same level of operation on same line):

So are you suggesting a micro-kernel architecture so that the Linux
kernel
can't get direct hardware access?  If so then that will never take
off, Linus
doesn't like it and there's the HURD for people who do.  I suggest
that you
investigate the HURD.

No, this would still essentially be linux. Both processes could have direct access to hardware. Hardware access apart from memory for the security thread wouldn't be neccessary and could be actually through the kernel itself, for which the password itself is not really needed. Like an extra FS driver.


> After Booting, the bootloader loads the Pre VM.  This can be
considered
> like the Linux Virtual Machine which interfaces between the Linux
> kernel and hardware, turning Linux system calls into the correct I/O
> mechanisms.

Firstly, there is nothing like a 1:1 mapping between system calls and
IO
mechanisms.  You could have Linux running over a virtual hardware
interface
such as UML.  But that has some significant performance issues and
doesn't
necessarily gain you much.

who said anything about 1:1? The arch vm translates a system call into a string of architecture-specific calls to enable most of the code in the linux kernel to be architecture-independent.

> This Pre VM, however, is minimally multithreading, unlike the
existing
> Linux VM (sort of).  It spawns two virtual processes, first the
> security VM, which sleeps until the interface makes a call to it,
and

Let's call these two processes two copies of UML Linux running on
Linux so
that we are talking about something that could possibly be
implemented.


With the UML argument -- you can't have a direct memory pipe between two uml kernels anyway, so this theory wouldn't work there; it's still dependant on networking.

> Once the OS has booted and the Authentication System starts, it
> switches its memory interface to be the security interface, while
the
> input remains in the linux kernel (This could be difficult to
achieve
> without writing some new calls to do kernel switching).

What do you mean by "kernel switching"?  Are you referring to having a

"Trusted Path" to the security code from an application?

I actually mean changing the memory space so that the process called by the kernel thread could have its memory pointers shifted to the security thread.


Back to the HURD,microkernel,platform thing, this isn't really what's in mind with the design on the HURD either -- none of this security method would be necessary anyway, because I think we can trust any backdoors or anything in on OSS O/S kernel itself to be found out pretty damn quick, so memory residue in the kernel isn't really a problem. Sorry to the list admins and "normal developers", but this thread is probably a waste of mailing list. It brings to light a little bit of undeveloped theory in case one wants to create a toy operating system, but isn't really that useful otherwise. Probably.

As to the kernel reloading into running systems... that was sarcasm as my own build up.

If anyone actually wants to open a mailing list kickstarted by these ideas, go ahead. But this ties it up for my input.

Francis Whittle
(fudje)

[ Next time, something useful ]



Reply to: