Re: [developer] A couple of kernel questions

[John Howard <echosoft.llc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8071 bytes --]

Nano-X (formerly MicroWindows) is a minimal replacement for both X11 and Win32 API. A Nano-X UI and Nuklear UI are also supported. Anti-grain rendering. Some
have integrated it to render to OpenGL, or Frame Buffer.

Nano-X is on github.

Thank you to the devs for your patience on this subject.

-- John

On Jul 17, 2024, at 3:22 PM, Lonnie Cumberland via illumos-developer <developer@lists.illumos.org> wrote:

Hi Joshua,

I sincerely Thank you for the in-dept discussion on these questions/ideas and will investigate them further.

Also, I am starting the stage of working on the prototype and am setting up but build environment for this purpose. Will probably use X11/Xorg to get started along with VNC from the Bhyve side but definitely will be seeing what it might take to port DirectFB2       over as well.

Lastly, I think that you are right and I will move to have more discussions on these things over at the "illumos-discuss" list and do apologize to everyone for the off-topic and tangential discussion not specifically related to kernel development.

Hope to see you over on the illumos-discuss list.

Best and have a great evening
Lonnie

> On 7/17/2024 4:09 PM, Joshua M. Clulow via illumos-developer wrote:
> On Wed, 17 Jul 2024 at 06:29, Lonnie via illumos-developer
> <developer@lists.illumos.org> wrote:
>> 1. As Illumos is designed for zones (VMs), I am wondering if there are driver and service zones implemented such that if a driver crashes then it does not heavily impact the OS in operation?   From what I understand so far, the drivers and system wide services are installed in the Global-Zone which makes me think of the Xen Type-1 Hypervisor in which these things are installed in their Dom0 which is similar to the Illumos Global-Zone (GZ)
> It's not so much that illumos is designed _for_ zones or VMs, as that
> we have first class features in the OS that support those things.
> Aside from those features, illumos is a UNIX operating system with a
> monolithic kernel.  Drivers are generally kernel modules, though there
> are limited areas in which drivers can be implemented in user mode
> software; e.g., ugen(4D) allows for user mode USB drivers, and one of
> the FUSE ports would allow for a user mode file system.  That said,
> because our consolidation can ship both kernel and user mode software,
> we can indeed relatively easily move some things into daemons where
> they might have ended up in the kernel in other systems.
> 
> We ship a lot of daemons for different purposes, supervised by smf(7)
> and in may cases deprivileged by rbac(7) and privileges(7) features in
> the OS.  In most or all cases, these daemons could crash and restart
> without necessarily bringing down other parts of the system.  If a
> daemon restart does cause unavailability, you could definitely file
> that as a bug to fix.
> 
>> 2. Another crazy thought that I had was about the possibly of investigating what it might take to (fork illumos for an experiment) and try to remove the dependencies on a hierarchal tree-based filesystem and to implement a type of "Property-Graph Database (PGDb)" filesystem.  The rationale here is that a hierarchal tree-based filesystem can easily be represented as well but that a PGDb filesystem also allows for assigning new types of attributes to files, blocks, objects, users, etc. and thus allowing for granular security on users at the application level.  Users can be allowed/disallowed to see/access application/files/block/objects and only authorized applications are "mapped" to a particular user.
> I think it's unlikely that we would move away from a hierarchical file
> system.  It's really at the core of a lot of UNIX abstractions.  We
> tend to focus on mandatory access control through privileges(7) and
> rbac(7) mechanisms.  Individual users, or processes, can be restricted
> from seeing quite a lot of other things occuring on the computer in
> other accounts, etc, by removing privileges from their processes.
> They can be prevented from making network connections, or seeing other
> processes in /proc, etc.  We're always interested in new security and
> sandboxing features, but would generally like them to build on and fit
> in with the existing designs where possible.  The core team is happy
> to help with design advice if someone wants to put together an illumos
> project discussion (IPD) document that covers a new sandboxing
> feature; see: https://github.com/illumos/ipd.
> 
> ZFS, our primary file system, has extensive support for extended
> attributes.  It also has rich support for NFSv4 ACLs, which allow for
> fine-grained permissions in the regular file system; see acl(7) for
> more details.  There is also support for other more complex
> attributes, such as marking things totally immutable; see fgetattr(3C)
> and chmod(1) for more details.
> 
>> 3. I could see that when a user does a login, then a blank empty zones is set up at which time their configured files, directories are mapped in to their container zone and allowed applications are only used. The users cannot escape their zone and does not have access to the rest of the system unless privilege's are elevated.  I know that "zlogin" can do this from the GZ, but perhaps automatically and full console since graphic display will be needed.
> You could achieve a lot of automatic provisioning for users on login
> through some combination of NSS and PAM modules and
> distribution-specific control software.  I don't think this would
> really be a core illumos feature, at least to begin with, but there's
> a lot of mechanism that could help you get there!
> 
> Graphics is obviously something of an uncharted challenge.  As I
> mentioned in your OmniOS thread, our DRM/KMS software needs work to be
> brought up to date, and there are probably new facilities that we
> would then need to add to the core OS to provide a richer graphical
> console experience.  It's also possible that you could, once DRM is
> sorted out, drive a lot of that from distribution-specific software
> like X11, or a port of DirectFB2, etc, without needing much or any
> additional core OS support.
> 
>> 4. One need that may be a challenge to get done will be the need for a enable/disable consoles such that a local users could use a hot-key (API call) to switch between zone consoles which would include graphics, audio, etc.   This would be akin to running multiple VirtualBox OSs, or VMware Guests in which you can step through the guest graphic tabs in fullscreen mode, perhaps. I am seeking to replicate that idea in Illumos to step through guests (maybe in Bhyve or native zones) that are in their own configured zone which is the thought.
> This is mostly the same as my comments on graphics above.  Some work
> will be required specifically on improving the graphical/desktop
> support we have, as part of a project like that.
> 
>> I am not sure how these things might be approached and/or tackled in illumos but wanted to start investigating them one by one and build up at the project evolves.
> I suspect most of what you want to do, you could get started by
> prototyping on top of facilities that exist already!  I can't stress
> enough that if you want the graphics stuff to work out, I would work
> on that first, as I think it's the biggest risk/unknown in your plans
> so far.
> 
>> Well, I thought that I would ask these questions here since they are more kernel related than OS configuration related and hope that you also find them interesting although may have already been considered in the past well.
> We generally try to keep the illumos developer list focused on
> specific bits of in-progress development (questions about how to
> proceed, code and design reviews), or about specific bugs or issues,
> etc.  Generally we would do broad, exploratory ideation on the
> illumos-discuss list.
> 
> Cheers.

illumos / illumos-developer / see discussions + participants + delivery options Permalink

[-- Attachment #2: Type: text/html, Size: 10216 bytes --]