Computer Old Farts Forum
 help / color / mirror / Atom feed
From: bakul at bitblocks.com (Bakul Shah)
Subject: [COFF] [TUHS] man-page style
Date: Mon, 19 Nov 2018 11:48:46 -0800	[thread overview]
Message-ID: <20181119194853.657EE156E40C@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Mon, 19 Nov 2018 12:53:31 -0500." <20181119175331.A0A9A18C076@mercury.lcs.mit.edu>

On Mon, 19 Nov 2018 12:53:31 -0500 jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
>
>     > All of this would be easily possible on the Mill arch. if ever it gets
>     > built. Mill has segments and protected function calls.
>
> What I found about that mostly talked about the belt stuff. Do you happen to
> have a pointer to the segment/call stuff?

This is a good talk re IPC and protection:

https://www.youtube.com/watch?v=XJasE5aOHSw

In the desciption below the video there is a
list of times where various topics are covered
so you can jump to what you want.

Slides here:
https://millcomputing.com/docs/inter-process-communication/

Ivan's talk on Security should also be of help:
https://www.youtube.com/watch?v=5osiYZV8n3U
https://millcomputing.com/docs/security/

The key implication is a thread can make a "portal" call,
where the same thread is now in a different protection domain.
No need for rendezvous & a couple of extra context switches to
a different thread, or trampoline through a higher privilege
kernel.  This callee function can only access what is visible
from its own protection domain. It can operate on caller's
memory data ony if the caller provides one time access to it.

>     > set-uid has its own issues. Plan9 doesn't have it.
>
> Ah, what were the issues (if you happen to know)?

The issue is setuid(uid,gid) process has *full* access*
available to uid,gid. If uid==0, now the process has superuser
access. Why should an install program have access to
/etc/passwd or have raw disk access or be able to root around
in kernel memory?  Typically you only want to provide very
limited access.


  reply	other threads:[~2018-11-19 19:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-19 17:53 jnc
2018-11-19 19:48 ` bakul [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-11-17 20:09 jnc
2018-11-18  5:33 ` gtaylor
2018-11-18  6:28 ` bakul
2018-11-18 21:24 ` tytso
     [not found] <20181116192941.DFB6218C073@mercury.lcs.mit.edu>
2018-11-16 20:46 ` gtaylor

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=20181119194853.657EE156E40C@mail.bitblocks.com \
    --to=coff@minnie.tuhs.org \
    /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).