Re: [PATCH] nvme: make sending wall-clock time to NVMe opt-in

[Daniel Colascione <dancol@dancol.org>]

Keith Busch <kbusch@kernel.org> writes:

> On Mon, Jul 13, 2026 at 04:34:43PM -0400, Daniel Colascione wrote:
>> Some NVMe devices maintain a persistent log, the PEL, of events like
>> power-on and thermal excursions. The NVMe Set Features (Timestamp)
>> command allows an operating system to inform the NVMe of the current
>> wall-clock time. Wall-clock timestamp updates are logged to the PEL
>> alongside other events. By correlating PEL records, an attacker can
>> infer a user's usage patterns and even guess at time zone changes.
>
> How does an attacker come to acquire PEL records if the system isn't
> already compromised?

The PEL can be read without any authentication whatsoever, so even an
otherwise completely measured secure-boot system with FDE could leak the
log to an evil maid. A sophisticated evil maid could execute some kind
of adaptive attack, but the PEL is right there and easy to read even for
an unsophisticated one-shot adversary.

Another thing to emphasize is that the log persists *through*
cryptographic sanitize, so you can "wipe" a drive using the strongest
available NVMe command, hand it to someone else, and still unwittingly
leak real-world usage patterns. It's a side channel I'd rather not have,
especially if I'm not getting any value from the timestamp.

>> The nvme_core.timestamps_enabled_default module parameter supplies the
>> default value of the per-controller flag. Default it to false as the
>> privacy-preserving choice. Users who want to provide controllers with
>> real-world time can set the module parameter to true or enable
>> the per-controller sysfs flag, perhaps via udev.
>> 
>> As an alternative, we could also get the timestamp updates out of the
>> kernel entirely and have interested users run nvme(1) to
>> update timestamps.
>
> The use cases for the timestamp feature are outside the specification.
> But I know of at least one implementation that uses it to determine how
> long it has been powered off so it can better apply correction to media
> drift. Yeah yeah, depending on the host for something so critical is
> pretty fragile, but it apparently worked out well enough. This proposal
> would break them.

We could make the timestamp-updating opt-out instead of opt-in or
require users of this hardware to change the module parameter. Also,
IIUC, nothing in the spec requires a host to use this command.

I mostly care about having *some* knob to turn this off. Right now, it's
unconditional. I'm happy with either opt-in or opt-out, although I have
a weak preference for the former.