From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 3eca002c for ; Thu, 1 Nov 2018 17:53:29 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 56BAAA2410; Fri, 2 Nov 2018 03:53:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EFB11A23F7; Fri, 2 Nov 2018 03:53:09 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 90907A2152; Fri, 2 Nov 2018 02:57:01 +1000 (AEST) Received: from mail-it1-f193.google.com (mail-it1-f193.google.com [209.85.166.193]) by minnie.tuhs.org (Postfix) with ESMTPS id 2731FA214E for ; Fri, 2 Nov 2018 02:56:56 +1000 (AEST) Received: by mail-it1-f193.google.com with SMTP id d6so3057197itl.4 for ; Thu, 01 Nov 2018 09:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jMQ4PmqZQD6MsawWKG+qd+fJAKyV6LdI8V7TtiYwtXQ=; b=D31hM2AewCPtcBKPHlw3JfqgZ6ofn6JNOA0sTNBNZnFV3D+6FWWR0grYr7lphLg1y0 j5bo+Zq14DQ+Tijm0lGL0RzXvmrMKfg1S5IuovobneB1LYcLSl2xVE0Bco4YPyXPcOJc VQJM1mHHjiSILWjk1hca5p6qLcJBcX9/mhTGJNVKXc/LcP7sP7u++9Oyn8Yyn58aam3n Oz52jHhlCO2y0TnjD+O4PEOEeIZpXcg81Xs5+QQkmntPM9+NneEilNN/Nu/7oYZj4Ha+ JYJJrSFr9KTVja/3j/5gkRjfXCptWFsmCRnzOTDYZYUlJwaF18mkbs8uH4s5+gueBtaO CyUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jMQ4PmqZQD6MsawWKG+qd+fJAKyV6LdI8V7TtiYwtXQ=; b=nn1wugltEFg91Tq2nyZfoeRlKrGl+4zvcV/uzz5sSWYt1gXOvbjEn8IJ4QdWInGzpj MHkwnUvvy/BAc++E2J5l+j1KNNW3+kVgay5AyFTLSylO45gF7SV5xhs0glKyFWhd1fw6 YLwcVF/mxqXZ5D2wyOIgoZftgWStdpywoIDwaI9gbUU9v7Bg6eFqEgLdJjgLaVKDhySc Ps9tOdz8dnGgJ4LvxLsraz4Et6QYUSKIj62/QFf2HtVPMrwF7HRJmlxT2KlWEaQj2OPg LuLlr/1IIj0iskmsRp2jHnd2yWafTevC5BR4AqtQr0HJ0M3PYVkcPmDn3nYA7ZAzqowV vlXw== X-Gm-Message-State: AGRZ1gLmXLimL5gOQ8oazNXnSyoI1mwUGrPn5dKfUuYOcO1Srks07Jml fOjh9guJr2PO6NFfQBKMsdsR92Cpicl3yxZxvDR7qQ== X-Google-Smtp-Source: AJdET5cNMRPQdVK9KZ4YChZ7yoJlPELJnFXkpxbQFO9Q7UdJtbcvv4OaVyLtn9OEd6+YvdS9mzrOPVsLjMr8znxcyiM= X-Received: by 2002:a02:31d:: with SMTP id y29-v6mr6881788jad.98.1541091415474; Thu, 01 Nov 2018 09:56:55 -0700 (PDT) MIME-Version: 1.0 References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> In-Reply-To: From: Warner Losh Date: Thu, 1 Nov 2018 10:56:44 -0600 Message-ID: To: ron minnich Content-Type: multipart/alternative; boundary="00000000000062f19105799d4e43" Subject: Re: [TUHS] Unix APIs: elegant or not? X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000062f19105799d4e43 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 1, 2018 at 10:48 AM ron minnich wrote: > > > On Thu, Nov 1, 2018 at 9:44 AM Warner Losh wrote: > >> >> >> There's another school of thought too that says the kernel has no >> business parsing strings with all the security implications of doing so... >> >> > yeah, it's an interesting question. But Unix is based on parsing strings. > The kernel already parses lots of strings for paths, for all kinds of > reasons, so adding another element in the kernel that uses paths seems > acceptable. > Well, if the nose of a camel comes in under the tent, the rest of the camel is sure to follow... Parsing a string path is rock simple, but are there two arguments or three for this command, and what happens if they are too long, or negative when you expect and fd, or or or. The CVE-archive is littered with people who thought parsing in the kernel was simple and easy... > The bigger problem for Plan 9 that started to bite was i8n. All the Plan 9 > messages are English, oops. All the control messages are english. And so > on. > > And, further, that network architecture I referenced is much less > efficient than the BSD model -- 5 system calls per accept! so that was > starting to hit us here on the Akaros project, since we imported the entire > Plan 9 network stack into akaros, along with the drivers. Linux left us in > the dust on network connections/second. We were going to change it had > Akaros continued. > That's the other reason to not do stings in the kernel: parsing is takes time. I'll grant there's a balance here: A single int fd is nice so you don't have to pass a pointer to the device call function and provides a level of abstraction that blocks many bad data attacks. But even with this interface there's been issues with improper range checks for some interfaces. Warner --00000000000062f19105799d4e43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Nov 1, 2018 at 10:48 AM ron minnich <rminnich@gmail.com> wrote:


On= Thu, Nov 1, 2018 at 9:44 AM Warner Losh <imp@bsdimp.com> wrote:


<= /div>
There's another school of thought too that says the kernel ha= s no business parsing strings with all the security implications of doing s= o...


yeah,= it's an interesting question. But Unix is based on parsing strings. Th= e kernel already parses lots of strings for paths, for all kinds of reasons= , so adding another element in the kernel that uses paths seems acceptable.= =C2=A0

Well, if the nose = of a camel comes in under the tent, the rest of the camel is sure to follow= ... Parsing a string path is rock simple, but are there two arguments or th= ree for this command, and what happens if they are too long, or negative wh= en you expect and fd, or or or. The CVE-archive is littered with people who= thought parsing in the kernel was simple and easy...
=C2=A0
The bigger problem for Plan 9 that started to bite was i8n. All the P= lan 9 messages are English, oops. All the control messages are english. And= so on.=C2=A0

And, further, that network architect= ure I referenced is much less efficient than the BSD model -- 5 system call= s per accept! so that was starting to hit us here on the Akaros project, si= nce we imported the entire Plan 9 network stack into akaros, along with the= drivers. Linux left us in the dust on network connections/second. We were = going to change it had Akaros continued.

That's the other reason to not do stings in the kernel:= parsing is takes time.

I'll grant there's= a balance here: A single int fd is nice so you don't have to pass a po= inter to the device call function and provides a level of abstraction that = blocks many bad data attacks. But even with this interface there's been= issues with improper range checks for some interfaces.

Warner=C2=A0
--00000000000062f19105799d4e43--