From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f66.google.com (mail-pl0-f66.google.com [209.85.160.66]) by dpdk.org (Postfix) with ESMTP id 15A4647CD for ; Thu, 17 May 2018 16:39:17 +0200 (CEST) Received: by mail-pl0-f66.google.com with SMTP id ay10-v6so2679129plb.1 for ; Thu, 17 May 2018 07:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VBSyzJZ0oo4GW0nOoffeHqgwuPedvEQlf1p1aPMDgjM=; b=sd3eQSqdQuFGd6wE+UvUoHHfV2lrweN9jRhCJ6bkWoUCp6EZ8xVJxIvpxRhTWV4uJo Kd9pDwIPsJSewrr5B1pEQlEs6HFlhDWYVrccnKNNb5NjUdX1Kli/B/kwGv52102fIY2f 2mi8EGRx5tvXNv2FSX1NH1KPuj174n1HaHG2XBpo0oRk427iRZqHs3xJu3ZFDB3SaM61 g66rMVJ3m3wOxy6l3lEREVaL7q7oYIm1P7uMJ71w6NGWURpdDhjFos7iG0zCT9qH/22a HXeTZ+kCbevTLtvKWZyAeLxuXojZasftBusYFwjsaOCLUmX0PNYnpbRiwb6/dUKGUXBO BGFA== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=VBSyzJZ0oo4GW0nOoffeHqgwuPedvEQlf1p1aPMDgjM=; b=tO0aDuHjKyu034lSOtRG/bRsiIxNwt9DBX/pH/NzZsCogirNtde4ixSgKVCmn/W6KL WU/9uZx+hS+5L4ZxxU6VDbrGubU5YBbwtPf5C7VxuEHx88V0U7r2w9hCKfYBW4gHeUl7 fEqSG8bxmlk0cJ85b6YqnLjMzU0EVf8yAdJ3Wj9RvY2M7mZkTTFnCWs2FTdWvT5W9rN9 AHwS/Xof2L25k+NcGMkFKgcPhtAbDaOALVSKQlfc8YrRRRj0XVxYL70v30L+1MMhkF60 yv7dqvR+oMxW7DpV/NBS/lZl/HOt3wqqIMUf7cxzU4LIu4LU8PxL47z4DxtNX/S1zGR2 LDMg== X-Gm-Message-State: ALKqPwdOLrksorunQD41zOrJ8BlKWCVGWIM75ilWxXa6sc5BcQeZVE8j 5N2W0vhWLgW/9wwRkI9dvhORpbCAXVQ= X-Google-Smtp-Source: AB8JxZo7lxAjlZj/o47HcDZldP49+SEcNqCBXVf6OZT090eCevKPoo9qUHOA+wvzturKiBvHZ5KVyw== X-Received: by 2002:a17:902:42c3:: with SMTP id h61-v6mr5465652pld.164.1526567956205; Thu, 17 May 2018 07:39:16 -0700 (PDT) Received: from xeon-e3 (204-195-35-107.wavecable.com. [204.195.35.107]) by smtp.gmail.com with ESMTPSA id r22-v6sm8011869pfh.61.2018.05.17.07.39.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 May 2018 07:39:16 -0700 (PDT) Date: Thu, 17 May 2018 07:39:12 -0700 From: Stephen Hemminger To: Ferruh Yigit Cc: Neil Horman , dev@dpdk.org, Christian Ehrhardt , Luca Boccassi , Maxime Coquelin Message-ID: <20180517073912.064c0a48@xeon-e3> In-Reply-To: <9a4178b1-f827-a9a9-ad03-96b8cc31f774@intel.com> References: <20180515165612.61243-1-ferruh.yigit@intel.com> <20180516114715.GA20004@hmswarspite.think-freely.org> <9a4178b1-f827-a9a9-ad03-96b8cc31f774@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] igb_uio: fail and log if kernel lock down is enabled X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 14:39:17 -0000 On Thu, 17 May 2018 14:23:46 +0100 Ferruh Yigit wrote: > On 5/16/2018 12:47 PM, Neil Horman wrote: > > On Tue, May 15, 2018 at 05:56:12PM +0100, Ferruh Yigit wrote: > >> When EFI secure boot is enabled, it is possible to lock down kernel and > >> prevent accessing device BARs and this makes igb_uio unusable. > >> > >> Lock down patches are not part of the vanilla kernel but they are > >> applied and used by some distros already [1]. > >> > >> It is not possible to fix this issue, but intention of this patch is to > >> detect and log if kernel lock down enabled and don't insert the module > >> for that case. > >> > >> The challenge is since this feature enabled by distros, they have > >> different config options and APIs for it. This patch is done based on > >> Fedora and Ubuntu kernel source, may needs to add more distro specific > >> support. > >> > >> [1] > >> kernel.ubuntu.com/git/ubuntu/ubuntu-artful.git/commit/?id=99f9ef18d5b6 > >> And a few more patches to > >> > > What exactly is the error you get when you load the igb_uio module? I ask > > because, looking at least at the Fedora patches, the BAR registers themselves > > aren't made unwriteable, its only userspace access through very specific > > channels that are gated on (things like /proc/bus/pci/...). From what I can see > > (again, not having looked at other implementations), kernel modules that load > > successfully should be able to modify bar registers, and otherwise function > > normally (as to weather they are permitted to load is another question). > > This patch is based on understanding on the effect of the lockdown patches, that > it will disable hardware access from userspace. > I don't have an environment to test this and indeed I am not very clear about > effects of the lockdown set. > > > > > The reason I ask this is twofold: > > > > 1) if a specific access is failing, that seems like it could be the trigger to > > use, rather than explicitly checking if the kernel is locked down. I don't see > > one expressly called, but if you're calling pci_write_config_* somewhere, and > > getting an EPERM error, thats a reason to fail the loading of igb_uio, based on > > the fact that you don't have permission to write to the appropriate hardware. > > > > 2) Its more than just the igb_uio module that will fail. Any attempt to pass a > > VF into a guest using user space tools (including the vfio scripts that dpdk > > includes), should fail. As such, it might be better to have some component in > > user space test one of the aforementioned restricted paths for writeability. > > Such an approach would be more generic, and eliminate the need to assemble a set > > of tests to see if the kernel is locked down. A more generic error message > > could then be logged and the dpdk could exit gracefully, weather or not igb_uio > > was loaded. > > With the existing patches, expectation is vfio will work but it will only effect > igb_uio. > > > > > Its probably also important to note here that, this lockdown patch, from my > > digging, has been carried in Fedora since December of 2016, and its still not > > made it upstream. Thats not to say that it will never do so, but it suggests > > that, given the 2 years of out of tree updates its received, there its use is > > both very specific and limted to users who understand its implications. This > > probably isn't something to make significant or hard-to-maintain changes to the > > dpdk (or any other software) over. > > Have same expectation that use will be specific and limited, that is why planed > to change only igb_uio to detect the case and return with a log, instead of > updating anything in the dpdk. > > in igb_uio the plan was just adding simple check, patches being not upstreamed > added more complexity, but not still I believe it is not significant or > hard-to-maintain change. The issue is that igb_uio is not secure since it allows userspace to setup DMA to any physical address. In lockdown mode, even root is not supposed to be able to peek and poke arbitrary memory. Actually, it would make more sense to just have code to block all UIO drivers in uio.c since uio_pci_generic has the same issue.