Re: Another security vulnerability

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

Thomas Koenig wrote:

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.

>
It doesn't need to eat opcode space if you only support one data type,
64-bit ints, and one address mode, [register].
Other address modes can be calculated using LEA.
Since these are rare instructions to solve a particular problem,
they won't be used that often, so a few extra instructions shouldn't matter.

Hm, I'm not sure it would actually be used rarely, at least not
the way I thought about it.

I envisage a "ldp" (load pointer) instruction, which turns on
prefetaching, for everything that looks like

foo_t *p = some_expr;

which could also mean something like

*p = ptrarray[i];

with a scaled and indexed load (for example), where prefixing
is turned on, and a "ldd" (load double data) instruction where,
explicitly, for

long int n = some_other_expr;

where prefetching is explicitly disabled.  (Apart from the security
implicatins, this could also save a tiny bit of power).