On 3 December 2017 at 17:10, listreader <suselist@cableone.net> wrote:
On Sun, 3 Dec 2017 09:58:46 +0100 Richard Brown <RBrownCCB@opensuse.org> wrote:
In my case I chose the Samsung 960 Pro NVME at 1TB which come at about €560 each, but sequential read speeds of 3500MB/sec (not a typo, BYTES, not Bits), and write speeds of 2100MB/sec
There are more reasonably priced options. If you're only interested in using an NVMe SSD for booting then you don't need 1TB; The 512GB model is half the price.
I bought a new workstation a couple weeks ago and one of the options was various Samsung 960 NVMe PRO's including the 2 TB at ~$1300 (~€1100 ?) the later to which I said, umm, no thank you for that :-/
My question to you, and to Greg F who also apparently has experience with these things, is: these come with hardware encryption. How does that work with linux, specifically openSUSE of course. Can you boot 42.3 off a hardware encrypted NVMe? If so, anything special need to be done to permit said booting?
I haven't used it much myself - all of the production nvme openqa.opensuse.org workers (which were/are Leap 42.2/3) didn't use the feature - We don't want to enter passwords when we're rebooting them. However I did my homework and currently the commonly believed 'best' way of using the hardware encryption is by using the support (if your BIOS has it) for unlocking it in and with the BIOS That way, when the BIOS is loading, it unlocks the device, and from that point on Linux we see and use the device just like a regular nvme (which is pretty much seen the same as a regular disk, just with a funny naming convention, eg /dev/nvme0n1p1) There are embryonic efforts for userspace and kernel tooling to enable the control and use of the hardware encrypted nvme support without needing to rely on BIOS support. I believe we have the kernel support in our kernels, I do not believe we have the userspace tooling packaged anywhere. But, given the tooling would require the disabling of SecureBoot, which actually does a good job of ensuring your boot process hasn't been tampered with, a solution using this software would arguably have a wider attack service than the BIOS unlock or the more generic dm-crypt/luks option with SecureBoot we already support in our openSUSE Packages. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org