From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13008 invoked from network); 10 Feb 2021 02:32:11 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 10 Feb 2021 02:32:11 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 0BB0C9503A; Wed, 10 Feb 2021 12:32:10 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B437F94F1A; Wed, 10 Feb 2021 12:31:48 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="VipxVOOm"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 134B794F1A; Wed, 10 Feb 2021 12:31:47 +1000 (AEST) Received: from mail-il1-f172.google.com (mail-il1-f172.google.com [209.85.166.172]) by minnie.tuhs.org (Postfix) with ESMTPS id 8955C94F19 for ; Wed, 10 Feb 2021 12:31:46 +1000 (AEST) Received: by mail-il1-f172.google.com with SMTP id m20so470335ilj.13 for ; Tue, 09 Feb 2021 18:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vI9THnjnv8yyHqnhiW9SF4QCdiP0cymbVNSIWBjL9I0=; b=VipxVOOmnBLJDjMg5xmkzjXlVd9Itd4ZYdvwrs6FxaBcKoh/tBGFjRcvnRAkrHjrYT qeBs9pncLQRm+YJ1V/IaFfzpgho0O1tDeVQMStoZWQuxECYffYMMdRZbWvH+wYUdXGE1 jRgmDIeBAyg2fRKVjSC2yiSj/09q6NlOQI4zwe9bTKt7hC7sUJ8Vtp5rludY3t69bd8l LaNcDxMvPWhqa7gVmJJoG/tCpPLEJaolagLlTTE278EG0tcFQins5tORG/9cffyM2cfe 1bMcVm2xU3tUhJJPfP+8jr5scWZsNc+EYeEVsv81yScV1REtW7uho/Bwc6nuzfbOIQBv aWyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vI9THnjnv8yyHqnhiW9SF4QCdiP0cymbVNSIWBjL9I0=; b=DLnq+wE40Gy49xpEMnFStRS8bITXwXHW+LDsj7n6E0NAHh98SWuZDM0BqCuxz5JXjX uO34inaKKQCJORbaPhV4t42bhRm3f/L/ck3Ls5G442XbONti3pQp8OW7va0hkAPM+3xU 5NzwCJYuMk927fnirz+lxTCRHxZjMjKdh3DLHC/2i9QOPdjt4428ZRzsOQliLjEXDS4A 7teyz3WtpnIPKS2gUlHAMxJ5hkb+ba/0JpgIqFV3x/behKoqdfyUga9icVFJvmQQnqZY 7vbvo+Asou3RCB87KHjKIj48l+ejRUKZTBnnHQqEuD4+dVy1VdoDMqn0LFVRCgXjmfqC oKeA== X-Gm-Message-State: AOAM533ay9pAaAYO1i1xIt51VV7YpHA4FEy9znaQFZsihxaGxqLScqy3 xzaMDP0g2nhv91PlHZ0nimFO65Bc2bdgdWX3L/pmFa6G X-Google-Smtp-Source: ABdhPJw4Nv+kXK9J4AYxRrkDUU56IqHHSJspi2lNP7uKpagmHeucUviXelY3M3UVbF0TppM81cjKgr0ARJVB0MYNvaI= X-Received: by 2002:a05:6e02:1787:: with SMTP id y7mr822146ilu.233.1612924305435; Tue, 09 Feb 2021 18:31:45 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ad5:48a1:0:0:0:0:0 with HTTP; Tue, 9 Feb 2021 18:31:44 -0800 (PST) In-Reply-To: References: From: Andrew Warkentin Date: Tue, 9 Feb 2021 19:31:44 -0700 Message-ID: To: tuhs@minnie.tuhs.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Macs and future unix derivatives X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 2/9/21, Theodore Ts'o wrote: > > Everything can be implemented in terms of a turing machine tape, so > I'm sure that's true. Whether or not it would be *performant* and > *secure* in the face of application level bugs might be a different > story, though. > seL4 basically provides no primitives other than send and receive, and UX/RT will just map read()/write()-family APIs onto send and receive (the IPC transport layer won't be trivial, but it will be simpler than those under most other microkernel OSes). Basically everything else will be implemented on top of the read()/write() APIs provided by the transport layer (memory mapping will sort of bypass it, but all user memory will be handled as memory-mapped files, even that which is anonymous on other systems). In order to better map onto seL4 IPC semantics, variants of read()/write() that operate on message registers and a shared buffer will be provided, but these will be compatible with each other and with the traditional versions (messages will be copied on read when a different variant was used to write them). Basically if there were something that couldn't be implemented efficiently and securely on top of a combination of read()/write() and shared memory, that would mean that it couldn't be securely implemented on top of IPC, and I'm not sure that there is anything like that. > > In fact, some of the terrible semantics of the Posix interfaces exist > only because there were traditional Unix vendors on the standards > committee insisting on semantics that *could* be implemented using a > user-mode library on top of normal file API's (I'm looking at you, > fcntl locking semantics, where a close of *any* file descriptor, even > a fd cloned via dup(2) or fork(2) will release the lock). So yes, > Posix fcntl(2) locking *can* be implemented in terms of normal file > API's.... AND IT WAS A TERRIBLE IDEA. (For more details, see [1].) > UX/RT's file locking will be implemented with RPCs to the process server just like open()/close() and the like (which will use read()/write()-family APIs underneath; the initial RPC connection to the process server will be permanently open but it will be possible to create new connections to manipulate the environment of child processes before starting them, so that fork() doesn't have to be a primitive anymore). AFAIK, little actually depends on those rather broken "close one FD and release all locks on that file" semantics, so UX/RT will implement more sane locking semantics by default. There will be a flag to revert to the traditional semantics (probably just implemented at the library level) in case anything actually depends on them. > > I could go on about other spectactularly bad ideas enshrined in POSIX, > such as telldir(2) and seekdir(2), which date all the way back to the > assumption that directories should only be implemented in terms of > linear linked lists with O(n) lookup performance, but I don't whine > about that as feature bloat imposed by external standards, but just > the cost of doing business. (Or at least, of relevance.) > The directory contents that normal user programs actually see on UX/RT will be in a standardized format managed by the VFS (since support for a limited form of union mounts will be built in). > > I'm not sure what you're referring to; if you mean the *at(2) system > calls, which is why they exist in Linux (not for !@#!? Windows file > streams support); they are needed to provide secure and performant > user-mode file servers for things like Samba. Trying to implement a > user-space file server using only the V7 Unix primitives will cause > you to have some really horrible Time of Use vs Time of Check (TOUTOC) > security gaps; you can narrow the TOUTOC races with some terrible > performance sucking impacts, but removing them entirely is almost > impossible. > I'm talking about implementing local filesystems in regular processes (rather than requiring them to be in the kernel) like in QNX or Plan 9, not about network filesystems (although of course network filesystem clients can be implemented on top of such an API). Linux has support for them through FUSE, but AFAIK it has performance issues and isn't very well integrated, so it isn't used all that much. When it comes to normal server processes, UX/RT will mostly depend on checking security on open() rather than on read()/write()-family APIs, which will limit the risk of TOCTTOU vulnerabilities. Where security does have to be checked on reads or writes (such as the ones underlying the RPC implementing open() itself), the data will be copied before checking. Using the traditional read()/write() instead of the new zero-copy equivalents should usually be good enough AFAIK, since they copy to a caller-provided buffer. > > That's because most people aren't going to port or rewrite application > software for some random OS, whether it is a research OS or someone's > new "simple, clean, reimplementation". And most users do expect to > have a working web browser.... and text editor..., and their favorite > games, whether it's nethack or spacewars, etc., etc., etc. > I'm very well aware of that. UX/RT will implement most Linux APIs (either in libraries, servers, or combinations of the two) and will have a Linux binary compatibility layer. The only major incompatibilities are likely to be with stuff that manages sessions and logins (since UX/RT will natively have a mostly process-oriented security model, with no way to fully revert to traditional Unix security outside of running programs in fakeroot containers).