On Thu, Jun 11, 2026 at 03:46:58PM +0800, Herbert Xu wrote:
> On Thu, Jun 11, 2026 at 03:30:14AM -0400, Michael S. Tsirkin wrote:
> > On Thu, Jun 11, 2026 at 12:43:09PM +0800, Herbert Xu wrote:
> > > On Sun, May 31, 2026 at 10:22:51AM -0400, Michael Bommarito wrote:
> > > >
> > > > + size = min_t(unsigned int, size, avail - vi->data_idx);
> > > > + idx = array_index_nospec(vi->data_idx, sizeof(vi->data));
> > > > + memcpy(buf, vi->data + idx, size);
> >
> > All the "malicious device" things are confusing. Spectre things -
> > doubly so.
> >
> > So if an access is speculated then CPU might speculate feeding a kernel
> > secret into RNG. And then the speculated RNG value maybe can be also
> > speculatively be used by some kernel code as an index
> > to trigger a cache access, finally leaking the secret?
> >
> > Maybe?
>
> The way Spectre works is if you have an actual instruction using
> idx directly. I don't see how that translates to memcpy.
I am not sure it has to be direct:
if (malicious_idx > SIZE)
return;
src += malicious_idx;
memcpy(&value, src, ...)
....
hash = complex_hash_of(value)
....
return p[hash * 512];
is IIUC still a valid spectre v1 gadget leaking a value beyong SIZE, or
did I miss something?
And rng is a kind of a complex hash, but I also think in that "...."
in the kernel is probably large enough to close any transient execution
window.
So sure, we can drop this.
> Cheers,
> --
> Email: Herbert Xu <[email protected]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
