From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4AA5C10F0B for ; Thu, 18 Apr 2019 07:01:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A1EB12184B for ; Thu, 18 Apr 2019 07:01:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="QG96egDR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725987AbfDRHBc (ORCPT ); Thu, 18 Apr 2019 03:01:32 -0400 Received: from mail-wr1-f68.google.com ([209.85.221.68]:37864 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725886AbfDRHBb (ORCPT ); Thu, 18 Apr 2019 03:01:31 -0400 Received: by mail-wr1-f68.google.com with SMTP id w10so1551326wrm.4 for ; Thu, 18 Apr 2019 00:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=2Jbg2nvyur1ZuaUEjOYV4EMJPD4jlzJV48TooYxtva4=; b=QG96egDR45+5WnrPo5iMXtowm78KqKYi+sHdztG6GPPJ5RoMS6gVBAwfg0p5vqWgrX AC1t5ML8HOqJ+57UnZxiFtm8q12uoKPoWfoi6OVbKjuF8umCouE73HzLvHV3p272tdXI 97bhesMzFcd+/fVPTegNEVqlxV2M7DA7ddo2izU8NXmqY+n/b+/QTopw4/sPOINunNpW wEn7EdAA1BAv3CJND6CQ7UEsleF4KddKur4KjjK8wMeriz8MJx06NsYhofOqt94HU4UG wI+9EKFerRtYOlyOVGvrxqCpxet9Ykeej+KF0XuAxG23WRmxNOMjCd5MOWSzjWTgU/S2 vr2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2Jbg2nvyur1ZuaUEjOYV4EMJPD4jlzJV48TooYxtva4=; b=Z/3nF9l2tgow5cjYwKchCB2q/b2ZZ0eXA4b1HeF9so79u2SmK6WCvLWtmpHP8/khSD KFCJ7rtkU//9UCRkEFYbPeJghT90cMjRVQ3Wv3ZH86OHtpzo+MIkWg+SjUSs1KUdAj5T EMBRrRQaVh3/XECv5GCP91s9ho3SWGy76F/GHkaVN05PURuw8oTFquFBXEQASJPSXzI0 8zlZKu6fdFY0y+7tB/mQ7fxxEmui5yKTD7gbMiFNvLq6lzdcphQqjgMnqKR546sTfFob WjQbmSpzOZDaXcVrtxmvVJi4p8YsZYitop93dvGaeygUBjhQNHPAMK6+MFefbO6cll0K w/mA== X-Gm-Message-State: APjAAAXIdhlxYHgG3d8cCD4qhezzMxzMr1Eo3cc3n5L7HjYDjjW3rcD/ x6xeOyKIbPYVvCz8yK7/Vt88lsA+2EI= X-Google-Smtp-Source: APXvYqwC1noGnEUlmi71Q0cbjrQ1s1XRMP8rwJjUhUjshvNtv8iZ0eqyggg1F2vXuTK8lE2TTKGsBg== X-Received: by 2002:a5d:4751:: with SMTP id o17mr60249007wrs.121.1555570890093; Thu, 18 Apr 2019 00:01:30 -0700 (PDT) Received: from ziepe.ca ([193.47.165.251]) by smtp.gmail.com with ESMTPSA id 4sm972638wmi.14.2019.04.18.00.01.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 18 Apr 2019 00:01:29 -0700 (PDT) Received: from jgg by jggl.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1hH132-0003SE-3J; Thu, 18 Apr 2019 04:01:28 -0300 Date: Thu, 18 Apr 2019 04:01:28 -0300 From: Jason Gunthorpe To: Kees Cook Cc: "Ruhl, Michael J" , Leon Romanovsky , Doug Ledford , Leon Romanovsky , RDMA mailing list , Andrea Arcangeli , Feras Daoud , Haggai Eran , Saeed Mahameed , linux-netdev Subject: Re: [PATCH rdma-next 3/6] RDMA/ucontext: Do not allow BAR mappings to be executable Message-ID: <20190418070128.GE3206@ziepe.ca> References: <20190416110730.32230-1-leon@kernel.org> <20190416110730.32230-4-leon@kernel.org> <14063C7AD467DE4B82DEDB5C278E8663BE6A5513@FMSMSX108.amr.corp.intel.com> <20190418055759.GA3155@mellanox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Apr 18, 2019 at 01:30:07AM -0500, Kees Cook wrote: > Anything running with READ_IMPLIES_EXEC (i.e. a gnu stack marked WITH > execute) should be considered broken. Now, the trouble is that this > personality flag is carried across execve(), so if you have a launcher > that doesn't fix up the personality for children, you'll see this > spread all over your process tree. What is doing rdma mmap calls with > an executable stack? That really feels to me like the real source of > the problem. Apparently the Fortran runtime forces the READ_IMPLIES_EXEC and requires it for some real reason or another - Fortran and RDMA go together in alot of cases. > Is the file for the driver coming out of /dev? Seems like that should > be mounted noexec and it would solve this too. (Though now I wonder > why /dev isn't noexec by default? /dev/pts is noexec... Yes - maybe? > Regardless, if you wanted to add a "ignore READ_IMPLIES_EXEC" flag to > struct file, maybe this bit could be populated by drivers? This would solve our problem.. How about a flag in struct file_operations? Do you agree it is worth drivers banning VM_EXEC for these truely non-executable pages? Thanks, Jason