[Info-vax] Reinventing VMS logical names (Fuchsia & Win NT)

[Dan Cross]

In article <e06bbee5-1846-4c6d-88cc-801f31aed2dfn at googlegroups.com>,
Jake Hamby (Solid State Jake) <jake.hamby at gmail.com> wrote:
>[snip]
>But NT is an old OS. What about current OS designs? Well, one
>thing I've noticed about exokernels, including Google's
>Fuchsia, which looks quite exokernel-like to me,

Hmm, what makes you say that?  I find that surprising, and I'd
wager that the folks who designed Fuchsia would as, well;
probably also the MIT folks who came up with the exokernel idea.

Fuchsia, or more properly Zircon, was designed to be a fairly
standard microkernel with a capability-based security
architecture.  Incidentally, they started from Little Kernel;
when they first announced internally at Google, I asked why they
hadn't started with seL4, which seemed like the obvious choice,
and the answer I got was that they found it very hard to develop
applications for seL4, and had more experience with lk.  I
gathered there were also some interpersonal dynamics at play.

There was a bit of an internal debate whether they should write
the kernel in C++ or Rust: they chose C++ based on toolchain and
language maturity grounds.  About 18 months later we started up
a new hypervisor project in Rust, and I talked to them about
their decision, and they seemed to indicate that if they'd
started about a year later they'd likely have chosen Rust over
C++.  C'est la vie.

>is they also
>have one or more object tree hierarchies, and they often use
>human-readable strings to access objects, like the NT Object
>Manager, or UNIX's "everything is a file in a single rooted
>hierarchy" model, except without having a single system-wide
>rooted hierarchy. Relevant section of Fuchsia docs:
>
>https://fuchsia.dev/fuchsia-src/concepts/process/namespaces
>
>"Objects are fundamentally nameless but they may be called many
>names by others.
>
> [snip]
>
>It is intended that object names be encoded and interpreted as
>human-readable sequences of UTF-8 graphic characters, however
>this property is not enforced by the namespace itself.
>
>Consequently clients are responsible for deciding how to
>present names which contain invalid, undisplayable, or
>ambiguous character sequences to the user."
>
>Fuchsia is an extremely ambitious project, but they ended up
>with 8-bit character strings for programs to find resources,
>just like UNIX "/dev", "/proc", "/sys", etc. paths, or VMS
>logical and device names (NT uses UTF-16 strings). Fuchsia's
>object relative paths have a max length of 4095 bytes.

Indeed.  The idea of using strings for users and applications to
name resources owned by the kernel is an old (and natural) one;
that this has been extended to arbitrary resources synthesized
by some OS component isn't really all that surprising.  Plan 9
did something very similar in 1989 with its very aggressive
application of the Unix "everything is a file" model to
"everything is a filesystem serving a small set of files
representing resources, that are imported and organized into
mutable per-process namespaces" (thus, a plan 9 namespace is
a capability of sorts).  But whereas plan 9 used a common file
protocol (9P) to effect resource sharing, allowing you to do
things like import a remote machine's network stack, Fuchsia
uses an IDL.

>If I were hired to work on the future of OpenVMS, the one
>non-obvious direction I'd explore (anticipating what customers
>aren't yet asking for) would be to extend logical name tables
>and VMS's existing concept of multiple object classes with
>common security attributes to provide a secure way for
>processes to grant capabilities to each other via special
>mailbox messages or special LNM entries in a shared table.

That actually sounds kind of interesting.

>Not only is this similar to how newer systems like Fuchsia,
>microkernels, and exokernels work, but you've been able to pass
>file descriptors and other security credentials across process
>boundaries in UNIX, at least on the BSDs and Linux, using UNIX
>domain sockets for some time.

It may be worthwhile noting that, in a lot of ways, modern Unix
systems treat file descrptors as credentials.  Indeed,
Unix-based capability systems such as Capscium represent a
capability as a file descriptor, allowing one to pass these
around via the usual mechanisms.

https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson.pdf

	- Dan C.