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
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
> > 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
> memory sometimes, they can do software<>channel<>device.
Like bus-mastering PCI cards. You can have two PCI cards talk to each
without involving main memory or CPU.
Sort of. Well, yeah, like that.
> You have a bootloader, a pre-vm that defines a minimal threading
> linux security vm (low priority) a linux kernel vm, a security
> interface to comminucate with the authentication system. These are
> in software; like so (same level of operation on same line):
So are you suggesting a micro-kernel architecture so that the Linux
can't get direct hardware access? If so then that will never take
doesn't like it and there's the HURD for people who do. I suggest
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
> like the Linux Virtual Machine which interfaces between the Linux
> kernel and hardware, turning Linux system calls into the correct I/O
Firstly, there is nothing like a 1:1 mapping between system calls and
mechanisms. You could have Linux running over a virtual hardware
such as UML. But that has some significant performance issues and
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
> Linux VM (sort of). It spawns two virtual processes, first the
> security VM, which sleeps until the interface makes a call to it,
Let's call these two processes two copies of UML Linux running on
that we are talking about something that could possibly be
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
> input remains in the linux kernel (This could be difficult to
> 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
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
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.
[ Next time, something useful ]