Information on implementing L4

[John]

On Fri, Sep 14, 2018 at 9:51 AM Paul Boddie <paul at boddie.org.uk> wrote:

> On Friday 14. September 2018 05.58.09 Andrew Warkentin wrote:
> >
> > Yes, I guess that would work, but you still have the problem of a
> > rather complex language runtime being part of the TCB, which you don't
> > get with an OS based on safer native code.
>
> I am very fond of dynamic languages which usually their own runtimes, but
> I
> would also be somewhat wary of deploying some of these runtimes in any
> kind of
> privileged role. (I don't know if that is what is being suggested, not
> having
> digested every word of this discussion - sorry!)
>
>
My scratch paper is this
https://drive.google.com/open?id=1enJbj6oeeYYIuUieRlockrnUFbCowwVPx5n2MDMW56Y

The Kernel-CLR runtime is basically a fancy privileged service loader, and
doesn't run userspace applications.  Basically, if you can load a driver,
you can get Kernel-CLR to process arbitrary input.

The most-simple CLR would be fairly small:  it only needs to read in the
instructions, map them to native instructions, and spit out an unoptimized
blob of memory.  You could, conceptually, provide things like optimization
and the garbage collector as separate services; even then, those might be
fairly small.  Being strict about what you interpret and produce (input
validation) helps; and the CLR itself would be C# and managed by itself
(yep) so easier to verify.


> As I recall, there are just-in-time compilers being used in the Linux
> kernel,
> maybe in the network firewall/rules functionality, and it is possible that
> this has already caused security problems. Of course, there are so many
> sources of such problems that it might be mean-spirited to single out just
> one
> of them.
>
>
There are.  I'd actually be looking at implementing iptables with undelying
high-performance approaches such as with nf-HiPAC.  https://www.hipac.org/


> > Developers probably aren't going to port to (or completely rewrite for
> > in the case of non-.NET languages) some obscure alternative OS.
>
> I see that nobody (prominently) mentioned JX whose documentation was quite
> approachable, I thought:
>
> https://en.wikipedia.org/wiki/JX_(operating_system)
>
> But one of the lessons from the phenomenon of Java is that people don't
> like
> to be told to rewrite all their stuff in a particular language, and
> although
> you can try and make the runtime language-neutral, some languages end up
> being
> more equal than others.
>
>
Yeah.  L4Mx would need to port in Minix and BSD drivers (I use the MIT
License), and there would be a lot of rewriting hardware drives into C#.

I've long considered the prospect of reverse paravirtualization, whereby
you put a paravirtualizing driver inside an HVM OS and pass the OS direct
IO mapping to a hardware device.  The PV driver then lets the hypervisor
send it requests, and it arbitrates with the local operating system.  In
other words:  the hypervisor is paravirtualized on the guest OS (reverse
paravirtualization).  This would enable using Linux as a mega-driver, while
L4Mx/Linux running a Linux kernel paravirtualized could do the opposite.


> > However, if you're writing your OS for some reason other than
> > practical real-world usage, then I guess compatibility doesn't matter
> > as much.
>
> Who is to say that an incompatible system does not have "practical
> real-world
> usage", though? I agree that compatibility would be helpful, and there are
> plenty of systems that exist only through the perseverence of their
> creators,
> only to fade away at some point, partly due to a lack of interest and
> difficulties integrating mainstream software.
>

Linux extended POSIX.  Extending what is now the Linux ABI seems an
excellent way to dive right in.


> Personally, I am also interested in what it would take to develop a
> vaguely
> standard multiserver system, albeit leveraging L4 technologies. A while
> back,
> people tried to get the Hurd working on L4 (Pistachio, I think), and I
> think
> there is potential to get something like that going on Fiasco.OC,
> particularly
> since the lack of capability support was supposedly the reason why the
> Hurd-L4
> work was abandoned.
>

I came up with the Kernel-CLR approach to abstract all platform-specific
implementations of generic kernel functions into interchangeable objects.
That way you run the same code but with a different Type implementing the
same interface and all the right stuff happens.

By building a Loader specifically for the target platform, creating an
assembly that implements those lowest-level functions correctly for the
platform, and providing an AOT of the Kernel-CLR translator in the
machine's native ISA, you can boot the same kernel (no recompile) and load
the same services (no recompile here, either).  Each binary runs on all
platforms.

If you have a Type that sends messages and does the right thing under the
hood, you can change how the underlying message passing architecture
physically works (so long as you have the same semantics):  what would
normally be an ABI change isn't even an API change.  Conceptually, a
service could run on completely-different microkernels with the same API if
they're written using Kernel-CLR—and even Kernel-CLR and the Kernel itself
use an assembly providing those classes implementing the underlying details
of IPC and the native ISA.

Imagine releasing one driver that runs on Windows, Linux, MacOSX, and HURD,
and on any of these on x86, x86-64, IA64, ARM, ARM64, MIPS, SPARC, SPARC64,
and RISC-V.  That would be impossible today; but with L4Mx and any
Kernel-CLR OS implementing L4Mx semantics, those any-OS-to-any-Architecture
mappings are implied.  Porting L4/Linux to L4Mx/Linux (by paravirtualizing
Linux and providing an adapter to communicate between the two
architectures) would allow Linux to take advantage of L4Mx drivers as well.

Of course, you'd need to recompile all userspace software to run on a new
CPU architecture.  A native x86-64 program isn't going to run on RISC-V.
Yes, of course, if you compile .NET Core and CoreFX Linux binaries for
RISC-V, you can load up .NET Core applications without a recompile; that's
downstream from the Kernel, and not everything is Python or Java or .NET.

You can get pretty close to "we rewrote a few thousand lines of code and
now the entire operating system and all software run on a totally-new ISA
and tuned as best an optimizing compiler can accomplish to the specifics
and enabled features of that platform."  I'm looking at that in a kernel.

Paul
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20180914/4e7a7ca5/attachment.htm>