linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Demi Marie Obenour <demi@invisiblethingslab.com>
Cc: Dave Chinner <david@fromorbit.com>,
	cve@kernel.org, gnoack@google.com, gregkh@linuxfoundation.org,
	kent.overstreet@linux.dev, linux-bcachefs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org, mic@digikod.net,
	Demi Marie Obenour <demiobenour@gmail.com>
Subject: Re: Unprivileged filesystem mounts
Date: Thu, 20 Mar 2025 12:00:25 -0400	[thread overview]
Message-ID: <20250320160025.GE1079074@mit.edu> (raw)
In-Reply-To: <Z9u1L_2o71uEiU4g@itl-email>

On Thu, Mar 20, 2025 at 02:26:41AM -0400, Demi Marie Obenour wrote:
> The L4 family of microkernels, and especially seL4, show that
> microkernels do not need to be slow.

With all due respect to folks who have wrked on L4 and its derivatives,
L4 is a research prototype.  The gap between a research prototype and
something that can actually be used in wide variety of use cases, from
smart watches, to mainframes, is... large.

If some company is willing to fund such work, I'd be very interested
to see what they can come up with.  I will note that Google has tried
dabbling in this space with Fuchsia, and getting to something that can
actually be shipped in a product has been a very long road.  To their
credit, they have managed to do this for a version of Nest Hub, but
most people would say that it is very far from being suitable for
Android or Chrome OS, and supprting data center workloads was
explicitly a non-goal by the Fuschia team.

See [1] for more details.  In 2018, it was reported that Google had
over 100 engineers working on Fuchsia starting in 2016, with the hopes
that it would be ready "in 5 years".  Per [2], apparently in 2024
Fuschia "is not dead", but work has slowed and there aren't as many
people working on it.  (Disclosure: I work at Google but all of my
recent knowledge about Fuchsia comes from news reports; the last time
I talked to anyone on the Fuchsia team was well before COVID.)

[1] https://www.bloomberg.com/news/articles/2018-07-19/google-team-is-said-to-plot-android-successor-draw-skepticism
[2] https://www.reddit.com/r/Fuchsia/comments/1g7x2vs/what_happened_to_fuchsia/

> I do agree that making a microkernel-based OS fast is hard, but on
> the other hand, running an entire Linux VM just to host a single
> application isn't exactly an efficient use of resources either.

Well, if you want to try to make a business case to VP's with
estimates of how many engineers this would require, probably in a
sustained effort taking at least 5 to 10 years, I cordially invite you
to make the attempt.  :-)

Given how cheap hardware has been geting, running multiple VM's on an
Android phone or a ChromeOS laptop might not actally be that
expensive, relative to the cost of the required number of software
engineers for some of the alternatives we've discussed on this thread.
There are ways that you can share the read-only text pages for the
kernel, etc., to optimize the overhead of the VM, for exaple.

It is also much easier to collavorate with SOC designers to create
hardware optimizations for a VM abstraction, as compared to creating
hardwae optmizations for a software-level OS abstraction such as a
container or microkernel task.  So I don't think it's a safe
assumption that VM overheads will always be unacceptable relative to
the alternatives.

Cheers,

					- Ted


  reply	other threads:[~2025-03-20 16:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2025030611-CVE-2025-21830-da64@gregkh>
2025-03-10 12:00 ` CVE-2025-21830: landlock: Handle weird files Mickaël Salaün
2025-03-10 13:49   ` Kent Overstreet
2025-03-10 14:36   ` Greg Kroah-Hartman
2025-03-10 23:42     ` Dave Chinner
2025-03-11  2:09       ` Kent Overstreet
2025-03-11  4:24         ` Dave Chinner
2025-03-11 10:50           ` Kent Overstreet
2025-03-11  2:19       ` Unprivileged filesystem mounts Demi Marie Obenour
2025-03-11  5:57         ` Dave Chinner
2025-03-11 11:01           ` Christian Brauner
2025-03-11 17:36             ` Al Viro
2025-03-11 17:43               ` Kent Overstreet
2025-03-11 17:54           ` Eric Biggers
2025-03-11 20:10           ` Demi Marie Obenour
2025-03-18  5:21             ` Dave Chinner
2025-03-19 14:55               ` Demi Marie Obenour
2025-03-19 16:59                 ` Theodore Ts'o
2025-03-19 17:32                   ` Demi Marie Obenour
2025-03-19 20:11                     ` Theodore Ts'o
2025-03-18 22:11             ` Theodore Ts'o
2025-03-19 17:44               ` Demi Marie Obenour
2025-03-19 21:25                 ` Theodore Ts'o
2025-03-20  6:26                   ` Demi Marie Obenour
2025-03-20 16:00                     ` Theodore Ts'o [this message]
2025-03-11  6:53       ` CVE-2025-21830: landlock: Handle weird files Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250320160025.GE1079074@mit.edu \
    --to=tytso@mit.edu \
    --cc=cve@kernel.org \
    --cc=david@fromorbit.com \
    --cc=demi@invisiblethingslab.com \
    --cc=demiobenour@gmail.com \
    --cc=gnoack@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@digikod.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).