linux-kernel - Re: [PATCH v3 4/5] nvme: Implement resume_from

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 28 Dec 2016 00:39:56 -0800
From:   Christoph Hellwig <hch@...radead.org>
To:     Scott Bauer <scott.bauer@...el.com>
Cc:     Jethro Beekman <kernel@...ekman.nl>, keith.busch@...el.com,
        sagi@...mberg.me, hch@...radead.org, Rafael.Antognolli@...el.com,
        linux-kernel@...r.kernel.org, linux-nvme@...ts.infradead.org,
        axboe@...com, viro@...iv.linux.org.uk, jonathan.derrick@...el.com
Subject: Re: [PATCH v3 4/5] nvme: Implement resume_from_suspend and SED
 Allocation code.

> for OPAL. In order to determine if the controller supports opal we need to allocate
> the previously mentioned structures anyway. I want to stay away from making payloads
> (specifically discovery0 ) payload in the nvme driver and allow the opal core to do a
> all the grunt work. In the future we'll probably have to refactor the core a bit to do
> just packet generation. It looks like at least for NVMe we're going to have to do a discovery
> to figure out whether we've got mutiple locking ranges per NS or just one global lr during
> initialization.

We might have to do discovery in the nvme driver - there also is the
ATA security feature supported by various consumer drives.  Jethro has
been doing some work in that direction, although driven by userspace
for now.