Received: by 10.213.65.68 with SMTP id h4csp879776imn; Tue, 20 Mar 2018 18:44:43 -0700 (PDT) X-Google-Smtp-Source: AG47ELusq6drP9Ifp8TZ3dBTO2WT1LRKHnlXqhz56R37O07gU6cT1YIx3vqhuERewnEf//Rr3XqU X-Received: by 2002:a17:902:768b:: with SMTP id m11-v6mr19101585pll.185.1521596683441; Tue, 20 Mar 2018 18:44:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521596683; cv=none; d=google.com; s=arc-20160816; b=S+vOxjK4iCO2ErKZUhTkQu5JrKImHjaQedL5KYdeo0X5R47KMQjMErfbJs8HY/xkZc ONpTVRV7KZihkT/FrWyA+k1Ug0snIAhM4vzIV9JH1iKQ4u4kmp3s8uhte7OWPxpn+ICo FvUd02YUZBFFOPRUFEmOsou6cZF+rXzGzIch2b/lISRRedj2X6t1Gf/rBpLVZNh3XT7d g5+6HK+hqf1bisYk2lLm/6AUBiBOruaOv6DbRZbGA6AZo/tQp1bJg0QDQvaqTmBIQ/ds AGHgToiMI41trY2H5DqGrUza24B6OH5hBm7p4zidPzqwxYaxeS2dm2vhNgV0ZiaTFoWD yqtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=cfCk2z82s5ZBzrHOw0eDBO7J/z+rehSdWRaNzOFanaE=; b=zkXcEa5EuZBAtFQhV0UkmKnTpu6hu0DNNmqTcI4dkWYbwQV3YwJ0EguzqJ3o+3wT95 76ZneLa4JNyuqTfYhsfP0y9H/K/c3f8fUfzSpgjEOcaoH3nPU6U7gnbKHpXFqeZsh1DZ 1nmpYYkXClqgV+W7B5p2MksFnEYwNfghsoxxg++Gc7XGd4JrPtqqm5lzOfZfE04Zwggq bY2u9spzO2wpwOqrRMruZkxly08BR+sXod0FIJnbHVGh++eIF3PApyAfNrUmTUq2nVqU CCLLi8DE0DY93rF4TegjyDKP3PDCvQJaBR0n+9P6RdWucPyhI+KjIp7UVyBUMELAd4Us tpBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bd3-v6si2990808plb.392.2018.03.20.18.44.29; Tue, 20 Mar 2018 18:44:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751601AbeCUBni (ORCPT + 99 others); Tue, 20 Mar 2018 21:43:38 -0400 Received: from mx-rz-2.rrze.uni-erlangen.de ([131.188.11.21]:51014 "EHLO mx-rz-2.rrze.uni-erlangen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018AbeCUBng (ORCPT ); Tue, 20 Mar 2018 21:43:36 -0400 Received: from mx-rz-2.rrze.uni-erlangen.de (mx-rz-2.rrze.uni-erlangen.de [IPv6:2001:638:a000:1025::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx-rz-2.rrze.uni-erlangen.de (Postfix) with ESMTPS id 405XdM0KrhzPjwN; Wed, 21 Mar 2018 02:43:35 +0100 (CET) Authentication-Results: mx-rz-2.rrze.uni-erlangen.de; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral X-Virus-Scanned: amavisd-new at boeck1.rrze.uni-erlangen.de (RRZE) X-RRZE-Flag: Not-Spam X-RRZE-Submit-IP: 62.210.105.116 Received: from uni-erlangen.de (62-210-105-116.rev.poneytelecom.eu [62.210.105.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: U2FsdGVkX19ySt2qFF82PJEcvHyRAdJl8efAXoh1cBE=) by smtp-auth.uni-erlangen.de (Postfix) with ESMTPSA id 405XdF0bLJzPkGB; Wed, 21 Mar 2018 02:43:28 +0100 (CET) Date: Wed, 21 Mar 2018 02:43:21 +0100 From: Jonas Rabenstein To: Scott Bauer Cc: Jonas Rabenstein , Christoph Hellwig , Jonathan Derrick , Jens Axboe , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 08/11] block: sed-opal: ioctl for writing to shadow mbr Message-ID: <20180321014321.xlkcyvcyr6j3usix@studium.uni-erlangen.de> References: <9f94be9c32887aacdcba75bd6a3902d0350eb987.1521482296.git.jonas.rabenstein@studium.uni-erlangen.de> <20180319195224.GA3380@lst.de> <20180320093604.qge2sdnc5jrud6kg@studium.uni-erlangen.de> <20180320220907.zdzf7baag6haaonm@sbauer-Z170X-UD5> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180320220907.zdzf7baag6haaonm@sbauer-Z170X-UD5> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 20, 2018 at 04:09:08PM -0600, Scott Bauer wrote: > On Tue, Mar 20, 2018 at 10:36:04AM +0100, Jonas Rabenstein wrote: > > On Mon, Mar 19, 2018 at 08:52:24PM +0100, Christoph Hellwig wrote: > > > On Mon, Mar 19, 2018 at 07:36:50PM +0100, Jonas Rabenstein wrote: > > > > Allow modification of the shadow mbr. If the shadow mbr is not marked as > > > > done, this data will be presented read only as the device content. Only > > > > after marking the shadow mbr as done and unlocking a locking range the > > > > actual content is accessible. > > > > > > I hate doing this as an ioctls. Can we make this a sysfs binary file > > > so that people can use dd or cat to write the shadow mbr? > > I already thought about providing a sysfs interface for all that instead > > of using ioctls. But as I am pretty new to kernel programming I do not > > have all the required insight. Especially, as writing the mbr requires > > the sed-opal password I am unsure how a clean sysfs interface to provide > > the password together with a simple dd would look like. > > Moreover I already have a patch that changes the 'void *data' argument > > to setup_opal_dev to a kobject pointer. As far as I know, this is the > > first step to get into the sysfs hierarchy. But as I do not have access > > to an NVMe drive and have no idea about its implementation, this change > > works only for the scsi side. > > Post what you have as an RFC (review for comment) and I will test for the NVMe > side, and or start a port for NVMe. It doesn't have to be perfect since you're > sending it out as RFC. It's just a base for us to test/look at to see if we > still like the sysfs way. Seems, like I failed to make my point in the previous message. I do not have more than adding a directory 'sed_opal' in sysfs for each sed-opal enabled disk. But that directory is completely empty. My further plans are, to fill up that directory with some public info like the one that gets printed by a call to TCG's 'sedutil-cli --query' command. The interesting part - where I am clueless how to achieve it - would be to have a binary sysfs attribute (like mentioned by Christoph) for the features (like shadow mbr) requiring some kind of authentication. Until there is any (good) idea, I do not think it is time for an RFC? -- Jonas