Re: Another security vulnerability

Thomas Koenig <tkoenig@netcologne.de> writes:

Michael S <already5chosen@yahoo.com> schrieb:
>

In case you missed it, the web page contains link to pdf:
https://gofetch.fail/files/gofetch.pdf

>
Looking the paper, it seems that a separate "load value" instruction
(where it is guaranteed that no pointer prefetching will be done)
could fix this particular issue.  Compilers know what type is being
loaded from memory, and could issue the corresponding instruction.
This would not impact performance.
>
Only works for new versions of an architecture, and supporting
compilers, but no code change would be required.  And, of course,
it would eat up opcode space.

The other way 'round seems to be a better approach: mark those loads
that load addresses, and then prefetch at most based on the data
loaded by these instructions (of course, the data-dependent prefetcher
may choose to ignore the data based on history).  That means that
existing programs are immune to GoFetch, but also don't benefit from
the data-dependent prefetcher (which is a minor issue IMO).

As for opcode space, we already have prefetch instructions, so one
could implement this by letting every load that actually loads an
address be followed by a prefetch instruction.  But of course that
would consume more code space and decoding bandwidth than just adding
a load-address instruction.

In any case, passing the prefetch hints to hardware that may ignore
the hint based on history may help reduce the performance
disadvantages that have been seen when using prefetch hint
instructions.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>