Re: Another security vulnerability

Liste des GroupesRevenir à c arch 
Sujet : Re: Another security vulnerability
De : tkoenig (at) *nospam* netcologne.de (Thomas Koenig)
Groupes : comp.arch
Date : 27. Mar 2024, 16:05:36
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uu1ck0$2tfbq$1@dont-email.me>
References : 1 2 3 4 5
User-Agent : slrn/1.0.3 (Linux)
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).

Date Sujet#  Auteur
24 Mar 24 * Another security vulnerability58Stephen Fuld
24 Mar 24 +* Re: Another security vulnerability4MitchAlsup1
25 Mar 24 i+* Re: Another security vulnerability2Stefan Monnier
26 Mar 24 ii`- Re: Another security vulnerability1Michael S
26 Mar 24 i`- Re: Another security vulnerability1Michael S
24 Mar 24 +* Re: Another security vulnerability10Lawrence D'Oliveiro
25 Mar 24 i+- Re: Another security vulnerability1Stefan Monnier
25 Mar 24 i`* Re: Another security vulnerability8Stephen Fuld
25 Mar 24 i `* Re: Another security vulnerability7Lawrence D'Oliveiro
26 Mar 24 i  +* Re: Another security vulnerability5MitchAlsup1
26 Mar 24 i  i`* Re: Another security vulnerability4Lawrence D'Oliveiro
27 Mar 24 i  i `* Re: Another security vulnerability3Stephen Fuld
28 Mar 24 i  i  `* Re: Another security vulnerability2Lawrence D'Oliveiro
28 Mar 24 i  i   `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 i  `- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability18Thomas Koenig
25 Mar 24 i+* Re: Another security vulnerability16Anton Ertl
26 Mar 24 ii+* Re: Another security vulnerability13Lawrence D'Oliveiro
26 Mar 24 iii`* Re: Another security vulnerability12Anton Ertl
5 Jun 24 iii `* Re: Another security vulnerability11MitchAlsup1
5 Jun 24 iii  +* Re: Another security vulnerability9Anton Ertl
11 Jun 24 iii  i`* Re: Another security vulnerability8MitchAlsup1
11 Jun 24 iii  i +* Re: Another security vulnerability6Stephen Fuld
11 Jun 24 iii  i i`* Re: Another security vulnerability5MitchAlsup1
11 Jun 24 iii  i i `* Re: Another security vulnerability4Stephen Fuld
11 Jun 24 iii  i i  `* Re: Another security vulnerability3Terje Mathisen
11 Jun 24 iii  i i   `* SSDs (was: Another security vulnerability)2Stefan Monnier
11 Jun 24 iii  i i    `- Re: SSDs1Chris M. Thomasson
11 Jun 24 iii  i `- Re: Another security vulnerability1MitchAlsup1
11 Jun 24 iii  `- Re: Another security vulnerability1MitchAlsup1
26 Mar 24 ii`* Re: Another security vulnerability2Anton Ertl
26 Mar 24 ii `- Re: Another security vulnerability1Anton Ertl
25 Mar 24 i`- Re: Another security vulnerability1Michael S
25 Mar 24 +* Re: Another security vulnerability22Anton Ertl
26 Mar 24 i`* Re: Another security vulnerability21Michael S
27 Mar 24 i `* Re: Another security vulnerability20Thomas Koenig
27 Mar 24 i  +* Re: Another security vulnerability2Thomas Koenig
27 Mar 24 i  i`- Re: Another security vulnerability1Thomas Koenig
27 Mar 24 i  +- Re: Another security vulnerability1Anton Ertl
27 Mar 24 i  `* Re: Another security vulnerability16Anton Ertl
27 Mar 24 i   `* Re: Another security vulnerability15MitchAlsup1
28 Mar 24 i    +* Re: Another security vulnerability4MitchAlsup1
29 Mar 24 i    i`* Re: Another security vulnerability3Paul A. Clayton
29 Mar 24 i    i `* Re: Another security vulnerability2Paul A. Clayton
30 Mar 24 i    i  `- Re: Another security vulnerability1MitchAlsup1
3 Apr 24 i    `* Re: Another security vulnerability10Stefan Monnier
3 Apr 24 i     `* Re: Another security vulnerability9Thomas Koenig
3 Apr 24 i      +* Re: Another security vulnerability6MitchAlsup1
4 Apr 24 i      i`* Re: Another security vulnerability5Thomas Koenig
4 Apr 24 i      i `* Re: Another security vulnerability4MitchAlsup1
4 Apr 24 i      i  +- Re: Another security vulnerability1MitchAlsup1
7 Apr 24 i      i  `* Re: Another security vulnerability2Paul A. Clayton
8 Apr 24 i      i   `- Re: Another security vulnerability1MitchAlsup1
5 Apr 24 i      `* Re: Another security vulnerability2Stefan Monnier
5 Apr 24 i       `- Re: Another security vulnerability1MitchAlsup1
25 Mar 24 `* Re: Another security vulnerability3John Savard
25 Mar 24  `* Re: Another security vulnerability2Michael S
26 Mar 24   `- Re: Another security vulnerability1Lawrence D'Oliveiro

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal