Hi all,
I've started to look at adding firmware updates for NVMe hardware to the LVFS project (realistically for Fedora >= 31, so don't get too excited). Before I know which vendors to approach, and what I need to ask for, I need to get some statistics about the NVMe hardware the "typical linux user" is using. I've expanded a lot on the https://blogs.gnome.org/hughsie/2018/08/17/nvme-firmware-i-need-your-data/ blog entry I wrote a few days ago if you'd like some more explanation and justification.
So, what do I would like you to do. You don’t need to reboot, unmount any filesystems or anything like that. Just:
Install nvme (e.g. dnf install nvme-cli) then do sudo nvme id-ctrl --raw-binary /dev/nvme0 > /tmp/id-ctrl
If that worked, run the following command:
curl -F type=nvme \ -F "machine_id="`cat /etc/machine-id` \ -F file=@/tmp/id-ctrl \ https://staging.fwupd.org/lvfs/upload_hwinfo
The first command isn’t doing anything with the firmware; it’s just asking the NVMe drive to report what it knows about itself. It should be 100% safe, the kernel already did the same request at system startup.
We are using your random machine ID to ensure we don’t record duplicate submissions -- if that makes you unhappy for some reason just choose some other random 32 byte hex string. In the binary file created by nvme there is the encoded model number and serial number of your drive; if this makes you uneasy please don’t send the file.
Many thanks,
Richard.
I will happily send info for several devices here which have NVMe, but my regular use desktop has three NVMe devices. I sent info for /dev/nvme0 but would you prefer that I append something to my machine ID so that I can send the others?
Simplified NVMe firmware updates would be great; I have several machines with Intel NVMe SSDs that had firmware bugs weird enough that I could install a machine using EXT4 but trying to install with XFS would lead to immediate FS corruption at boot time.
- J<
On Mon, 20 Aug 2018 at 20:13, Jason L Tibbitts III tibbs@math.uh.edu wrote:
but would you prefer that I append something to my machine ID so that I can send the others?
Yes please, just change the last two digits. I think it always has to be 32 hex chars in size, but it doesn't have to be a machine ID.
Simplified NVMe firmware updates would be great; I have several machines with Intel NVMe SSDs that had firmware bugs weird enough that I could install a machine using EXT4 but trying to install with XFS would lead to immediate FS corruption at boot time.
You're the second person to mention the Intel bug, I'll certainly prioritize that, although I'm not super confident about Intel specifically. Thanks for the data.
Richard
On Mon, Aug 20, 2018 at 09:18:59AM +0100, Richard Hughes wrote:
Hi all,
I've started to look at adding firmware updates for NVMe hardware to the LVFS project
Love the idea ;)
Install nvme (e.g. dnf install nvme-cli) then do sudo nvme id-ctrl --raw-binary /dev/nvme0 > /tmp/id-ctrl
I don't have any nvme hardware, so I can't help with that, but the command below raises an issue. Some time ago we started discouraging directly exporting the machine-id value. The reason is that it is a permanent identifier and exposing it has privacy and security implications. An library function sd_id128_get_machine_app_specific [1] was added, which takes the machine-id and hashes it with an application-specific identifier. The idea is that each application can use a stable id for the machine, but it is not possible to go back to the original machine-id or even to connect different applications on the same machine.
If you ask, "OK, how do I use this?", then the answer is, short of writing a quick C program or maybe calling python and using CFFI, is that it's not directly available.
Exposing this functionality has been on our todo list, for a while, and your upload script is provides a good use case. I opened a PR in systemd upstream to add a tool that provides this functionality [2]. Please take a look and comment on the proposed interface. But even it is merged quickly, this does not provide any solution for today.
If that worked, run the following command:
curl -F type=nvme \ -F "machine_id="`cat /etc/machine-id` \ -F file=@/tmp/id-ctrl \ https://staging.fwupd.org/lvfs/upload_hwinfo
My suggestion for now would be do something like this instead:
id="$(c=`(cat /etc/machine-id|echo nvme)|sha256sum`; echo ${c:0:32})" curl -F type=nvme \ -F "machine_id=$id" \ -F file=@/tmp/id-ctrl \ https://staging.fwupd.org/lvfs/upload_hwinfo
[1] https://www.freedesktop.org/software/systemd/man/sd_id128_get_machine_app_sp... [2] https://github.com/systemd/systemd/pull/9898
Zbyszek
We are using your random machine ID to ensure we don’t record duplicate submissions -- if that makes you unhappy for some reason just choose some other random 32 byte hex string. In the binary file created by nvme there is the encoded model number and serial number of your drive; if this makes you uneasy please don’t send the file.
Please do not use backtick characters (decimal 96, octal 0140, hex 0x60) in shell scripts. They do not nest, they are hard to read. The default shell /bin/bash offers replacements $( ... ) and $(< filename) which are better.
-F "machine_id="`cat /etc/machine-id` \
Replace with
-F "machine_id="$(< /etc/machine-id) \
id="$(c=`(cat /etc/machine-id|echo nvme)|sha256sum`; echo ${c:0:32})"
That's a real bug. 'echo' fails as a pipeline.
id="$(c=$(echo $(< /etc/machine-id)nvme | sha256sum); echo ${c:0:32})"