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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 527F0C10DCE for ; Thu, 7 Dec 2023 19:02:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1443802AbjLGTCg (ORCPT ); Thu, 7 Dec 2023 14:02:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233077AbjLGTCb (ORCPT ); Thu, 7 Dec 2023 14:02:31 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A3B6171A for ; Thu, 7 Dec 2023 11:02:37 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06B60C433C8; Thu, 7 Dec 2023 19:02:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701975757; bh=Lp4XJ1aqwUEf86+3xhp9+XdmCpF1YtsDAR77+7S8C10=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Ll0TFuur7xZX3Jve0cKmqyLBvYhGcwQteAtzj617bQsTT6j/C2VqH0dlyYJIIBHXM w+NUQszJRHPzIyAMMEnLRIi/Px9joMoIigtyY5eKzBAcver2lgzduAd9nJGIHiln/8 447val4HGq706N32t+0SZpopA7ZOz/7TBE6gTQhQU2jTjqn6fQ0NizCLQ/44KjVRBx 6rNu6qaI7KuN0ZvgIJ/UZWeBiNj85cHJWDAPGzvlEe2dhd59iFg9TxsQq5FiMQytA/ lKwSWc8z0L1g3Icj8bbyofkyVGBCLIAaB1Nkq10wtJNNlcpF/1QwIgQDczwOs3u/KA +BVmRodNhhaLw== Date: Thu, 7 Dec 2023 11:02:36 -0800 From: Saeed Mahameed To: Aron Silverton Cc: Jakub Kicinski , Greg Kroah-Hartman , Jason Gunthorpe , David Ahern , Arnd Bergmann , Leon Romanovsky , Jiri Pirko , Leonid Bloch , Itay Avraham , linux-kernel@vger.kernel.org, Saeed Mahameed Subject: Re: [PATCH V3 2/5] misc: mlx5ctl: Add mlx5ctl misc driver Message-ID: References: <20231128103304.25c2c642@kernel.org> <2023112922-lyricist-unclip-8e78@gregkh> <20231204185210.030a72ca@kernel.org> <20231205204855.52fa5cc1@kernel.org> <20231207092329.3ec04dca@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07 Dec 12:06, Aron Silverton wrote: >On Thu, Dec 07, 2023 at 09:23:29AM -0800, Jakub Kicinski wrote: >> On Thu, 7 Dec 2023 10:41:25 -0600 Aron Silverton wrote: >> > > I understand that having everything packaged and shipped together makes >> > > life easier. >> > >> > I think it is a requirement. We operate with Secure Boot. The kernel is >> > locked down. We don't have debugfs access, even if it were sufficient, >> > and we cannot compile and load modules. Even without Secure Boot, there >> > may not be a build environment available. >> >> This 'no debugfs' requirement is a kernel lockdown thing, I presume? >> Are we expected to throw debugfs out the window and for all vendors >> to reimplement their debug functionality via a misc driver taking >> arbitrary ioctls? Not only does that sound like a complete waste of >> time and going backward in terms of quality of the interfaces, needing >> custom vendor tools etc. etc., but also you go from (hopefully somewhat) >> upstream reviewed debugfs interface to an interface where the only >> security assurance is vendor telling you "trust me, it's all good". > >IIRC, with lockdown, we can read from debugfs IFF the entries' >permissions are 0400. We cannot write. It's not suitable for >implementing an interactive debug interface. I would like to add that debugfs is usually used to expose the driver software states, as it evolves and changes with the driver code, but as I explained in the other email, it's clearly not a good solution to expose arbitrary objects of complex devices, that require interactive and selective debug interfaces tailored to the user use-case.