From: Keith Busch <kbusch@kernel.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: make sending wall-clock time to NVMe opt-in
Date: Mon, 13 Jul 2026 14:52:26 -0600 [thread overview]
Message-ID: <alVQCljd3a0dRRPw@kbusch-mbp> (raw)
In-Reply-To: <20260713203443.322748-1-dancol@dancol.org>
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 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.
next prev parent reply other threads:[~2026-07-13 20:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-13 20:34 [PATCH] nvme: make sending wall-clock time to NVMe opt-in Daniel Colascione
2026-07-13 20:52 ` Keith Busch [this message]
2026-07-13 21:05 ` Daniel Colascione
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alVQCljd3a0dRRPw@kbusch-mbp \
--to=kbusch@kernel.org \
--cc=axboe@kernel.dk \
--cc=dancol@dancol.org \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox