Re: Another security vulnerability

EricP <ThatWouldBeTelling@thevillage.com> schrieb:

Thomas Koenig wrote:

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'm referring to your load with prefetch disable.
For these particular loads it's users could likely tolerate the
"overhead" of an extra LEA instruction to calculate the address,
and don't need all 7 integer data types.

If it was LEA-only, it would need some kind of pragma in the code
which said "use this more cumbersome and slower, but more
safe version".

For that reason, I would probably prefer a separate version
which is implicitly safe and does not have any other drawbacks
for performance, with no code changes.

If it's worth the opcode space...