Problem with new uapi header in Linux kernel 4.4+

Problem with new uapi header in Linux kernel 4.4+

[Jan Luca Naumann]

Hey,

at the moment I try to install a tool called "sedutil"[1]. The tool
manages self encrypting drives that conform to the TCG OPAL 2.0
specification.

The program uses in the current version i.a. ioctl() to communicate with
NVMe disks (see header [2] and source file [3]). The problem is that the
tool uses the no longer to the user space exported header file
"linux/nvme.h". In the new uapi header "linux/nvme_ioctl.h" are the
enumeration "nvme_admin_opcode" and the structure "nvme_id_ctrl" no
longer available that are used in the source code...

Since I do not have much experience with ioctl/NVMe and the upstream
author has no time at the moment, I want to ask you what would be the
best attempt to fix this.

Thank you in advance and best regards,
Jan

[1] https://github.com/Drive-Trust-Alliance/sedutil
[2]
https://github.com/Drive-Trust-Alliance/sedutil/blob/master/linux/DtaDevLinuxNvme.h
[3]
https://github.com/Drive-Trust-Alliance/sedutil/blob/master/linux/DtaDevLinuxNvme.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20161006/d77ab0b5/attachment-0001.sig>

Problem with new uapi header in Linux kernel 4.4+

[Keith Busch]

On Thu, Oct 06, 2016@05:15:04PM +0200, Jan Luca Naumann wrote:
> Hey,
> 
> at the moment I try to install a tool called "sedutil"[1]. The tool
> manages self encrypting drives that conform to the TCG OPAL 2.0
> specification.
> 
> The program uses in the current version i.a. ioctl() to communicate with
> NVMe disks (see header [2] and source file [3]). The problem is that the
> tool uses the no longer to the user space exported header file
> "linux/nvme.h". In the new uapi header "linux/nvme_ioctl.h" are the
> enumeration "nvme_admin_opcode" and the structure "nvme_id_ctrl" no
> longer available that are used in the source code...
> 
> Since I do not have much experience with ioctl/NVMe and the upstream
> author has no time at the moment, I want to ask you what would be the
> best attempt to fix this.

Yeah, we changed the uapi to only contain the what's necessary for the
user-kernel interface. We don't want user space to depend on the kernel
header for structure definitions when the kernel has no use for some them.

For the nvme-cli project, we define everything. I'm up for turning parts
of this into a shared library that sedutil and others can use.

Problem with new uapi header in Linux kernel 4.4+

[Christoph Hellwig]

On Thu, Oct 06, 2016@07:09:48PM -0400, Keith Busch wrote:
> Yeah, we changed the uapi to only contain the what's necessary for the
> user-kernel interface. We don't want user space to depend on the kernel
> header for structure definitions when the kernel has no use for some them.
> 
> For the nvme-cli project, we define everything. I'm up for turning parts
> of this into a shared library that sedutil and others can use.

FYI, one issue is the the Linux nvme.h is GPLv2 only like much of the
kernel, making it hard to use for things like sedutils that use GPLv3+.
I'd be fine with relicing my contributions to it under GPLv2+, but I
don't sign up for contacting everyone that ever touched it and get
their permission..

Problem with new uapi header in Linux kernel 4.4+

[Jan Luca Naumann]

Hey,

the license issue was the reason I'm looking for a better solution than
just copy the relevant parts from the nvme.h file.

Best regards,
Jan

Am 07.10.2016 um 09:29 schrieb Christoph Hellwig:
> On Thu, Oct 06, 2016@07:09:48PM -0400, Keith Busch wrote:
>> Yeah, we changed the uapi to only contain the what's necessary for the
>> user-kernel interface. We don't want user space to depend on the kernel
>> header for structure definitions when the kernel has no use for some them.
>>
>> For the nvme-cli project, we define everything. I'm up for turning parts
>> of this into a shared library that sedutil and others can use.
> 
> FYI, one issue is the the Linux nvme.h is GPLv2 only like much of the
> kernel, making it hard to use for things like sedutils that use GPLv3+.
> I'd be fine with relicing my contributions to it under GPLv2+, but I
> don't sign up for contacting everyone that ever touched it and get
> their permission..
> 
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20161007/385ead8c/attachment.sig>

Problem with new uapi header in Linux kernel 4.4+

[Bauer, Scott]

-----Original Message-----
From: Linux-nvme [mailto:linux-nvme-bounces@lists.infradead.org] On Behalf Of Jan Luca Naumann
Sent: Thursday, October 6, 2016 9:15 AM
To: linux-nvme at lists.infradead.org
Subject: Problem with new uapi header in Linux kernel 4.4+

Hey,

at the moment I try to install a tool called "sedutil"[1]. The tool manages self encrypting drives that conform to the TCG OPAL 2.0 specification.

The program uses in the current version i.a. ioctl() to communicate with NVMe disks (see header [2] and source file [3]). The problem is that the tool uses the no longer to the user space exported header file "linux/nvme.h". In the new uapi header "linux/nvme_ioctl.h" are the enumeration "nvme_admin_opcode" and the structure "nvme_id_ctrl" no longer available that are used in the source code...

Since I do not have much experience with ioctl/NVMe and the upstream author has no time at the moment, I want to ask you what would be the best attempt to fix this.

Thank you in advance and best regards,
Jan

[1] https://github.com/Drive-Trust-Alliance/sedutil
[2]
https://github.com/Drive-Trust-Alliance/sedutil/blob/master/linux/DtaDevLinuxNvme.h
[3]
https://github.com/Drive-Trust-Alliance/sedutil/blob/master/linux/DtaDevLinuxNvme.cpp

----

If you want it to *just work*: 
1) Place the attached nvme.h file in /usr/include/liunx/
2) Modify sedutil/linux/DtaDevLinuxNvme.cpp
     Add #include <linux/nvme_ioctl.h>
3) rebuild

This is what I did a while ago to get this to build. Just so you know I was having issues with this upstream version of sedutil not actually working on a opal-enabled controller. I had to checkout version 1.12 for it to work.
https://github.com/Drive-Trust-Alliance/sedutil/tree/1.12.

For what it is worth the kernel will soon have OPAL support built in so you won't have to do this weird hack, and use a
tool that is no longer maintained. 

Thanks,
Sott

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nvme.h
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20161006/f9228ead/attachment.h>

Problem with new uapi header in Linux kernel 4.4+

[Christoph Hellwig]

Hi Scott,

> For what it is worth the kernel will soon have OPAL support built in 
> so you won't have to do this weird hack, and use a tool that is no
> longer maintained. 

What's the ETA for OPAL support?  We had a patch from Intel for it
half a year ago, but the submitter didn't follow up on the review
feedback.  (Same for the simple ATA security unlock scheme submitted
by someone else).

Problem with new uapi header in Linux kernel 4.4+

[Scott Bauer]

On Fri, Oct 07, 2016@12:31:11AM -0700, Christoph Hellwig wrote:
> Hi Scott,
> 
> > For what it is worth the kernel will soon have OPAL support built in 
> > so you won't have to do this weird hack, and use a tool that is no
> > longer maintained. 
> 
> What's the ETA for OPAL support?  We had a patch from Intel for it
> half a year ago, but the submitter didn't follow up on the review
> feedback.  (Same for the simple ATA security unlock scheme submitted
> by someone else).

I or Rafael will send a series sometime next week or early the week after...
assuming some final testing all goes to plan.

Problem with new uapi header in Linux kernel 4.4+

[Jan Luca Naumann]

Hey,

this sound very nice :-) OPAL supported directly by the kernel would be
very good.

Thank you and best regards,
Jan

Am 07.10.2016 um 16:31 schrieb Scott Bauer:
> On Fri, Oct 07, 2016@12:31:11AM -0700, Christoph Hellwig wrote:
>> Hi Scott,
>>
>>> For what it is worth the kernel will soon have OPAL support built in 
>>> so you won't have to do this weird hack, and use a tool that is no
>>> longer maintained. 
>>
>> What's the ETA for OPAL support?  We had a patch from Intel for it
>> half a year ago, but the submitter didn't follow up on the review
>> feedback.  (Same for the simple ATA security unlock scheme submitted
>> by someone else).
> 
> I or Rafael will send a series sometime next week or early the week after...
> assuming some final testing all goes to plan.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20161008/5c79dae2/attachment.sig>