[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v7 1/2] drivers/misc: sysgenid: add system generation id driv
From: |
MacCarthaigh, Colm |
Subject: |
Re: [PATCH v7 1/2] drivers/misc: sysgenid: add system generation id driver |
Date: |
Wed, 24 Feb 2021 23:00:46 +0000 |
User-agent: |
Microsoft-MacOutlook/16.44.20121301 |
On 2/24/21, 2:44 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> The mmap mechanism allows the PRNG to reseed after a genid change. Because
> we don't have an event mechanism for this code path, that can happen
minutes
> after the resume. But that's ok, we "just" have to ensure that nobody is
> consuming secret data at the point of the snapshot.
Something I am still not clear on is whether it's really important to
skip the system call here. If not I think it's prudent to just stick
to read for now, I think there's a slightly lower chance that
it will get misused. mmap which gives you a laggy gen id value
really seems like it would be hard to use correctly.
It's not uncommon for these user-space PRNGs to used quite a lot in very
performance critical paths. If you negotiate a TLS session that uses an
explicit IV, the RNG is being called for every TLS record sent. Same for IPSec
depending on the cipher-suite. Every TLS hello message has 28-32 bytes of data
from the RNG, or if you've got ECDSA as your signature algorithm, it's inline
again. Using RSA_PSS? Same again. Many Post-Quantum algorithms are even more
veraciously entropy hungry. We examine the compiled instructions for ours by
hand to check it's all as tight as it can be.
To give more of an idea, several crypto libraries took out the getpid() guards
they had for fork detection in the RNGs, though VDSO could have helped there
and I'm not sure they would have needed to if VDSO were more widely used at the
time. I don't think we'd get a patch into OpenSSL/libcrypto that involves a
full syscall. VDSO might be ok, but even that's not going to have the speed
that a single memory lookup can do with the mmap/madvise approach ... since we
already have to use WIPEONFORK.
In practice I don't think it will be that hard to use correctly; snapshots and
restores of this nature really have to happen only when the activity is
quiescent. If operations are in-flight, it's not easy to reason about the
potential multi-restore problems at all and it only makes sense to think about
transactional correctness at the level of all transactions that may have been
in-flight. The mmap solution is more about integrating with existing library
APIs and semantics than it is about somehow solving that at the kernel level.
That part has to be solved at the system level.
-
Colm
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH v7 1/2] drivers/misc: sysgenid: add system generation id driver,
MacCarthaigh, Colm <=