Information on implementing L4

[John]

On Fri, Sep 14, 2018 at 7:58 AM Andrew Warkentin <andreww591 at gmail.com>
wrote:

> On 9/14/18, John <john.r.moser at gmail.com> wrote:
> >
> > It's a compiler, the same as gcc.  In some situations, equivalent C# and
> > C++ code have compared with the C# program being faster in business logic
> > sections.
> >
>
> Is that on highly CPU-bound code, or just I/O-bound code?
>
>
CPU-bound code.  Things like flat array loops.  When you get into
implementing stuff on List<T> and the like, there's a lot of overhead
because of how C# implements its linked lists; although you can say the
same for arrays versus Std::List in C++.  Std::List is apparently faster
than List<T>.

The usual analysis is that you can't make the comparison because some code
will be faster and some slower; this is the same as Objective-C vs. C++, or
Rust vs. C++.  C# has a garbage collector, which adds another system that
may stop the world and otherwise create interruptions; although there are
ways around that.

>
> >>
> >> >
> >> > I designed a way for the CLR to self-host:  it'd be written in C#, and
> >> > running on itself.  This is still theoretical, of course.
> >> >
> >>
> >> I'd think you'd have to statically compile it to native code first.
> >>
> >>
> > You'd have to perform the translation ahead of time and then store the
> CIL,
> > native, and instrumentation data in an image.  When you load the image,
> > it's the same as if a CLR had loaded the original CIL and gotten it
> JIT'd;
> > except the CLR is the JIT result, and the CIL is the CLR.  Runs on
> itself.
> >
>
> 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.
>
>
Fair enough.  You're overestimating that particular problem, though:
besides that the Kernel-CLR itself would be fairly small (the .NET runtime
is mostly huge standard libraries), it only runs against microkernel
services.  If you can load a microkernel service, you have kernel-level
access and don't need to exploit the CLR.

Basically, the CLR is equivalent to Linux's loadable kernel module loader.


> >
> >> To me, language-based OSes have always seemed interesting but a bit
> >> impractical and limiting. A language-based OS would face more of a
> >> challenge when it comes to success in the real world than a
> >> conventional OS would (that's one reason why I'm writing an advanced
> >> Unix-like OS, since that is what is most likely to be used in the real
> >> world).
> >>
> >
> > The plan is to run a Linux userspace by providing the Linux-specific ABI.
> >
>
> Developers probably aren't going to port to (or completely rewrite for
> in the case of non-.NET languages) some obscure alternative OS.
> They'll just say "oh, it runs Linux applications, so our Linux port is
> good enough", and users will probably pass it over because there will
> be few native applications, and Linux applications will be
> second-class citizens (unless you actually manage to integrate Linux
> applications and allow them to take advantage of your OS's advanced
> features, but that sounds like it might be tricky in a non-Unix-like
> language-based OS).
>

Potentially.  Things like systemd, udev, iptables, and direct rendering
should work out of the box.  Many advanced subsystems, such as KVM-flipping
hypervisors (you push a key, the monitor and keyboard are now natively
another OS domain) and virtual file systems (you can mount device:/mnt/foo
at /mnt/bar on several systems, and the kernel handles a call to open
/mnt/bar/qux by passing it through:  multiple OS Domains can natively use
the same file system in read-write mode) are transparent to applications.
The Local Security Authentication Service—an abstraction which allows an OS
to provide or use a particular security domain as a source of users and
group, such that one LDAP connection or /etc/passwd source is accessed
through the device on multiple OS domains—requires a PAM module.  KVM would
use the native HVM (non-paravirt).

Things get advanced when you start playing with capabilities-based security
or using OS domains to strongly sandbox.  The Control OS Domain (like Xen
Dom0) could pass to an OS domain the Capability to create paravirtualized
domains.  An Ubuntu Linux system running on this and specifically-aware of
the capability could then not only provide a PAM module for LSAS, but also
create an OS Domain with reduced Capabilities sharing the same Network
interface (it can listen on the same adapter, MAC, and IP) with restricted
ports.  That OS Domain isn't run under the Ubuntu domain, but rather
directly next to it; the Ubuntu domain simply has a capability allowing it
to access that domain, and the init and login systems strip that capability
from child processes except for the management application, etc.  The new
OS Domain has a read-only mount of Ubuntu's own root, with its own /tmp,
and writable areas for Samba's dynamic data files in /var/lib/samba and
whatnot:  it provides Active Directory authentication.

To do all that, you need to be aware of things like LSAS, Capability-based
security, and the capability to create paravirtualized domains.  You could,
instead, just use the cgroups interface and run it all under Docker.


> An advanced Unix-like OS would have a much easier time integrating
> Linux applications (even in its native environment, UX/RT will
> implement Linux-specific APIs where it makes sense to do so, and its
> Linux binary compatibility layer will be more or less transparent,
> allowing Linux programs to integrate reasonably well with the rest of
> the OS and take advantage of many of its advanced features).
>
>
That's the idea:  if we implement Minix's resurrection service
architecture, L4's high-performance architecture, and Linux's complete ABI,
we can run Linux userspace as an L4/Minix natively.  Any special things
like advanced schedulers, ZFS, paravirt, and the like are either magic
under the hood or things that are available to binaries targeting the L4Mx
ABI or using exposed devices.

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.
>
>
Eh, right now I'm writing up an outline of what can be done based on what
has been done in the real world and what is accomplished by combining those
things in interesting new ways.  If one of my business ventures takes off,
I'll set cash aside to fund a research group to actually implement it,
which will include releasing it as yet another Linux distribution.

At the moment, this is just feeding my addiction for all kinds of
knowledge.  I've burned out a few times from putting too much stuff in my
brain at once.

_______________________________________________
> 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/af603419/attachment.htm>