On Thu, Jun 11, 2026 at 03:58:17AM -0400, Michael S. Tsirkin wrote: > 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;
Wait but vi->data_idx isn't even under the hypervisor's control. It's an index maintained by our own driver. So how can it be malicious? Cheers, -- Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
