Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Another security vulnerability
Date: Wed, 27 Mar 2024 15:05:36 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <uu1ck0$2tfbq$1@dont-email.me>
References: <utpoi2$b6to$1@dont-email.me>
 <2024Mar25.082534@mips.complang.tuwien.ac.at>
 <20240326192941.0000314a@yahoo.com> <uu0kt1$2nr9j$1@dont-email.me>
 <VpVMN.731075$p%Mb.618266@fx15.iad>
Injection-Date: Wed, 27 Mar 2024 15:05:36 +0100 (CET)
Injection-Info: dont-email.me; posting-host="518bc0805b9cb00d427055eddddea606";
	logging-data="3063162"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18OoydnkF3GOZ74aRxlG1EX57lPTcakDcc="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:BFSZux5w2rYt9aTqRMywJsKf6WI=
Bytes: 2655

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).