From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH v3] igb_uio: fail and log if kernel lock down is enabled Date: Thu, 17 May 2018 14:16:24 -0400 Message-ID: <20180517181623.GB21980@hmswarspite.think-freely.org> References: <20180516101851.2443-1-ferruh.yigit@intel.com> <20180516144220.21235-1-ferruh.yigit@intel.com> <20180517113406.GA21980@hmswarspite.think-freely.org> <2f41af01-acf7-8fce-26bf-52ad21eac696@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, Christian Ehrhardt , Luca Boccassi , Maxime Coquelin , Stephen Hemminger To: Ferruh Yigit Return-path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id D12AC7EDF for ; Thu, 17 May 2018 20:17:21 +0200 (CEST) Content-Disposition: inline In-Reply-To: <2f41af01-acf7-8fce-26bf-52ad21eac696@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, May 17, 2018 at 02:26:12PM +0100, Ferruh Yigit wrote: > On 5/17/2018 12:34 PM, Neil Horman wrote: > > On Wed, May 16, 2018 at 03:42:20PM +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. > >> > > I still need to ask, what exactly is the error you're seeing with inserting the > > uio module? The lockdown patch set restricts BAR address changes, but via paths > > acessible from user space, igbuio should still insert and initalize just fine > > (or so it would seem to me). Why not fix this by detecting the problem during > > the user space library initalization, where you can do so via a standard method > > that works accross distributions? > > I have seen you comment on other thread, this v3 was just to fix a silly > mistake, lets continue discussion in other thread. > Copy that, thank you Neil