From Sebastien.Roy@Sun.COM Fri Mar 21 09:57:14 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2LGvDgV015170 for ; Fri, 21 Mar 2008 09:57:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2LGv6bC008436 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Fri, 21 Mar 2008 16:57:13 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JY300H15B3B5K00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Mar 2008 09:57:11 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JY300CFKB3A2EC0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Mar 2008 09:57:10 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2LGv9d9017394 for ; Fri, 21 Mar 2008 16:57:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JY300H019Z8OF00@mail-amer.sun.com> (original mail from Sebastien.Roy@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Mar 2008 10:57:09 -0600 (MDT) Received: from [129.148.174.103] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JY3008Y4B38L390@mail-amer.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Fri, 21 Mar 2008 10:57:08 -0600 (MDT) Date: Fri, 21 Mar 2008 12:57:08 -0400 From: Sebastien Roy Subject: PSARC 2008/208 Flexible Credentials for Kernel Door Upcalls Sender: Sebastien.Roy@Sun.COM To: psarc-ext@Sun.COM Message-id: <47E3E8E4.20605@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.9 (X11/20080115) Status: RO Content-Length: 2344 I'm submitting this self-reviewed case for myself. It is closed approved automatic. Flexible Credentials for Kernel Door Upcalls Release Binding: Patch Stability Level: Consolidation Private Summary ------- This case introduces a new kernel door upcall function which takes a cred_t pointer. This will allow kernel door clients to specify the credentials to be associated with a given upcall, and therefore to control the ucred_t returned by a door server's door_ucred() call. Details ------- PSARC 1998/344 introduced the Sun Private door_ki_upcall() function to allow the kernel to make door calls from kernel space to user space door servers. Door servers obtain the credentials of a caller by issuing door_ucred(), which currently returns a ucred_t based on the credentials of the calling thread. When the kernel does an upcall using door_ki_upcall(), the calling thread (i.e., curthread) can be a user thread executing a system call, a kernel taskq thread, etc. As a result, when a door server issues door_ucred() when servicing a door upcall, the credentials of the caller are not necessarily those associated with the kernel (i.e., "kcred"), and the kernel has no control over what credentials will be used for its upcall. The kernel therefore cannot execute a door upcall with elevated privileges beyond that of the calling thread. This can be problematic if the kernel needs to execute a door operation which requires a privilege which the current thread does not have. A workaround for this problem might be to have the kernel spawn a kernel thread whose purpose is to perform an upcall. This case proposes an easier solution, which is a new door upcall function which allows the caller to specify the credentials associated with the call. int door_ki_upcall_cred(door_handle_t, door_arg_t *, cred_t *); A new function is preferable over modifying the signature and semantics of the existing door_ki_upcall() function, as the door_ki_upcall() function is used by multiple consolidations, and it would be too risky to track down and modify all existing uses. As such, the existing door_ki_upcall() function's semantics remains unchanged, and will simply call through to door_ki_upcall_cred() with a NULL cred_t pointer, indicating that door_ki_upcall_cred() should simply use the current thread's credentials. From sacadmin Thu Jun 26 14:06:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QL6GLH002859 for ; Thu, 26 Jun 2008 14:06:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m5QL68W9025721; Fri, 27 Jun 2008 05:06:11 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3300E039AAZ900@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Jun 2008 14:06:10 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K330089P9AAM580@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Jun 2008 14:06:10 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5QL658g740558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 14:06:05 -0700 (PDT) Received: (from jwadams@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m5QL65nQ740557; Thu, 26 Jun 2008 14:06:05 -0700 (PDT) Date: Thu, 26 Jun 2008 14:06:05 -0700 From: Jonathan Adams Subject: PSARC 2008/208 Flexible Credentials and Result Limits for Kernel Door Upcalls To: psarc@sun.com Cc: Bart Smaalders , Sebastien Roy , William Roche Message-id: <20080626210605.GB686824@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Authentication-warning: jurassic-x4600.sfbay.sun.com: jwadams set sender to jonathan.adams@sun.com using -f User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 2310 This is an update to: PSARC 2008/208 Flexible Credentials for Kernel Door Upcalls: New Name: Flexible Credentials and Result Limits for Kernel Door Upcalls Release Binding: Patch (unchanged) Stability Level: Consolidation Private (unchanged) Status: Closed Approved Automatic (unchanged, self-review) Update: In order to simplify upcall results processing, the interface described by PSARC 2008/208: int door_ki_upcall_cred(door_handle_t, door_arg_t *, cred_t *); is being renamed and extended to allow limits on the amount of results returned to the caller. This is similar to the interfaces from: PSARC 2005/144 Door Interface Revisions which introduced interfaces to limit the amount of data and descriptors a client is allowed to send to a door server. Upcalls have a similar problem: any upcall server can return any amount of data and descriptors to the kernel, even if the upcall invoker has known limits on the amount of data or descriptors it will accept. Adding this interface moves the unexpected results handling code away from every upcall user and to the centralized doorfs code, reducing code complexity. The door_ki_upcall_cred() interface is renamed and extended to be: int door_ki_upcall_limited(door_handle_t, door_arg_t *, cred_t *, size_t max_data, uint_t max_desc); which limits to the maximum data and descriptors the door server can return using door_return() to max_data and max_desc, respectively. If the upcall server passes too much data to door_return(), it will fail with E2BIG. If the client passes too many descriptors, it will fail with EMFILE. This matches the existing door_return() failure codes: door_return(3C): ... ERRORS The door_return() function fails and returns to the calling process if: E2BIG Arguments were too big for client. ... EMFILE The client has too many open descriptors. ... The new interface is still Consolidation Private. It's cred_t argument is treated as in the original case. Interfaces ---------- Interface Stability ----------------------------------------------------------------- door_ki_upcall_cred() Removed (was Consolidation Private) door_ki_upcall_limited() Consolidation Private References ---------- PSARC 2005/144 Door Interface Revisions From sacadmin Thu Jun 26 15:57:58 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QMvvOX007082 for ; Thu, 26 Jun 2008 15:57:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5QMvqtd022499; Thu, 26 Jun 2008 23:57:54 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3300401EGH0I00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Jun 2008 15:57:53 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K33001O1EGG1D30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 26 Jun 2008 15:57:53 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m5QMvqeE003483; Thu, 26 Jun 2008 17:57:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m5QMvphV003482; Thu, 26 Jun 2008 17:57:51 -0500 (CDT) Date: Thu, 26 Jun 2008 17:57:51 -0500 From: Nicolas Williams Subject: Re: PSARC 2008/208 Flexible Credentials and Result Limits for Kernel Door Upcalls In-reply-to: <20080626210605.GB686824@eng.sun.com> To: Jonathan Adams Cc: psarc@sun.com, Bart Smaalders , Sebastien Roy , William Roche Mail-followup-to: Jonathan Adams , psarc@sun.com, Bart Smaalders , Sebastien Roy , William Roche Message-id: <20080626225751.GE2735@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20080626210605.GB686824@eng.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 114 Shouldn't this also go to psarc-ext? The original case was open... Or is there an associated security bug here? From sacadmin Thu Jun 26 16:31:14 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5QNVEqw008371 for ; Thu, 26 Jun 2008 16:31:14 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5QNVDpo764862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 16:31:13 -0700 (PDT) Received: (from jwadams@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m5QNVDHc764861; Thu, 26 Jun 2008 16:31:13 -0700 (PDT) Resent-Message-Id: <200806262331.m5QNVDHc764861@jurassic-x4600.sfbay.sun.com> X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: jwadams set sender to jwadams@eng.sun.com using -f Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5QL658g740558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jun 2008 14:06:05 -0700 (PDT) Received: (from jwadams@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id m5QL65nQ740557; Thu, 26 Jun 2008 14:06:05 -0700 (PDT) X-Authentication-Warning: jurassic-x4600.sfbay.sun.com: jwadams set sender to jonathan.adams@sun.com using -f Date: Thu, 26 Jun 2008 14:06:05 -0700 From: Jonathan Adams To: psarc@sun.com Cc: Bart Smaalders , Sebastien Roy , William Roche Subject: PSARC 2008/208 Flexible Credentials and Result Limits for Kernel Door Upcalls Message-ID: <20080626210605.GB686824@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Resent-From: jwadams@eng.sun.com Resent-Date: Thu, 26 Jun 2008 16:31:13 -0700 Resent-To: psarc@sac.sfbay.sun.com Status: RO Content-Length: 2310 This is an update to: PSARC 2008/208 Flexible Credentials for Kernel Door Upcalls: New Name: Flexible Credentials and Result Limits for Kernel Door Upcalls Release Binding: Patch (unchanged) Stability Level: Consolidation Private (unchanged) Status: Closed Approved Automatic (unchanged, self-review) Update: In order to simplify upcall results processing, the interface described by PSARC 2008/208: int door_ki_upcall_cred(door_handle_t, door_arg_t *, cred_t *); is being renamed and extended to allow limits on the amount of results returned to the caller. This is similar to the interfaces from: PSARC 2005/144 Door Interface Revisions which introduced interfaces to limit the amount of data and descriptors a client is allowed to send to a door server. Upcalls have a similar problem: any upcall server can return any amount of data and descriptors to the kernel, even if the upcall invoker has known limits on the amount of data or descriptors it will accept. Adding this interface moves the unexpected results handling code away from every upcall user and to the centralized doorfs code, reducing code complexity. The door_ki_upcall_cred() interface is renamed and extended to be: int door_ki_upcall_limited(door_handle_t, door_arg_t *, cred_t *, size_t max_data, uint_t max_desc); which limits to the maximum data and descriptors the door server can return using door_return() to max_data and max_desc, respectively. If the upcall server passes too much data to door_return(), it will fail with E2BIG. If the client passes too many descriptors, it will fail with EMFILE. This matches the existing door_return() failure codes: door_return(3C): ... ERRORS The door_return() function fails and returns to the calling process if: E2BIG Arguments were too big for client. ... EMFILE The client has too many open descriptors. ... The new interface is still Consolidation Private. It's cred_t argument is treated as in the original case. Interfaces ---------- Interface Stability ----------------------------------------------------------------- door_ki_upcall_cred() Removed (was Consolidation Private) door_ki_upcall_limited() Consolidation Private References ---------- PSARC 2005/144 Door Interface Revisions