From patchwork Mon Mar 19 21:42:49 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rob Clark X-Patchwork-Id: 10408 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1S9kMM-00047P-DP for patchwork@linuxtv.org; Mon, 19 Mar 2012 22:43:22 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-3) with esmtp for id 1S9kML-0003Zd-Ft; Mon, 19 Mar 2012 22:43:22 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755773Ab2CSVmz (ORCPT ); Mon, 19 Mar 2012 17:42:55 -0400 Received: from mail-yx0-f174.google.com ([209.85.213.174]:49088 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753631Ab2CSVmy (ORCPT ); Mon, 19 Mar 2012 17:42:54 -0400 Received: by yenl12 with SMTP id l12so5882417yen.19 for ; Mon, 19 Mar 2012 14:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:x-mailer; bh=VtPPm6zkp2h2wDVY+uJu6WHLi2+5OKzvL93e4hnMAkQ=; b=rmaAA4hgeeAaQ00Z/QzJlcsjXHLZ4fAEE1AGHWPdGIabI042b/X3JLYn8zQaNHav6b KCy7rK61zLxxgC3ZlFNLYRyMBhHwmkoPrmzMAv3/QeVG78URIiCcsHqTmRtW/q5pGsdy PIZBXZLATbqY7bD3sqQkvbOWrci076v9LbQXi0AJ05PpOZPvtshbN7yLI7cBWxtcsREg NxB01e/ORB7FgmsSptUysiTIUhkosZ0ZUXJfveJhqh6hQNHkbTY4RIOkBq2mngrenlfh ZTjByGGjdJcSlx2JKTCeAsDc+/qIi3ZhBAVC4rheokjEcvCXuGkftc4ViKS+TTNLYicR GCPA== Received: by 10.60.0.196 with SMTP id 4mr2428601oeg.0.1332193374036; Mon, 19 Mar 2012 14:42:54 -0700 (PDT) Received: from localhost (ppp-70-129-134-19.dsl.rcsntx.swbell.net. [70.129.134.19]) by mx.google.com with ESMTPS id yw3sm8411861obb.7.2012.03.19.14.42.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 14:42:52 -0700 (PDT) From: Rob Clark To: linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org Cc: patches@linaro.org, daniel.vetter@ffwll.ch, sumit.semwal@linaro.org, Rob Clark Subject: [PATCH] dma-buf: document fd flags and O_CLOEXEC requirement Date: Mon, 19 Mar 2012 16:42:49 -0500 Message-Id: <1332193370-27820-1-git-send-email-rob.clark@linaro.org> X-Mailer: git-send-email 1.7.5.4 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.213316 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DATE_TZ_NEG_0500 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS ' From: Rob Clark Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter --- Updated version of Daniel's original documentation patch with (hopefully) improved wording, and a better description of the motivation. Documentation/dma-buf-sharing.txt | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 225f96d..3b51134 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -223,6 +223,24 @@ Miscellaneous notes: - Any exporters or users of the dma-buf buffer sharing framework must have a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. +- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set + on the file descriptor. This is not just a resource leak, but a + potential security hole. It could give the newly exec'd application + access to buffers, via the leaked fd, to which it should otherwise + not be permitted access. + + The problem with doing this via a separate fcntl() call, versus doing it + atomically when the fd is created, is that this is inherently racy in a + multi-threaded app[3]. The issue is made worse when it is library code + opening/creating the file descriptor, as the application may not even be + aware of the fd's. + + To avoid this problem, userspace must have a way to request O_CLOEXEC + flag be set when the dma-buf fd is created. So any API provided by + the exporting driver to create a dmabuf fd must provide a way to let + userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). + References: [1] struct dma_buf_ops in include/linux/dma-buf.h [2] All interfaces mentioned above defined in include/linux/dma-buf.h +[3] https://lwn.net/Articles/236486/