On Fri, Sep 14, 2018 at 9:51 AM Paul Boddie <paul@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@os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers