EricP <ThatWouldBeTelling@thevillage.com> writes:
>There has been a lot of research on *value* speculation though
>I don't think any has made it into the commercial market.
>For example, value speculation allows speculative forwarding
>of a store value to a subsequent load and then at load retire
>checks that the value was correct.

Zen3 has features controllable by chicken bits: "speculative store
bypass" and "predictive store forwarding"; We have discussed them in
the thread starting with <2021Apr10.132712@mips.complang.tuwien.ac.at>
(https://news.novabbs.com/computers/article-flat.php?id=16188&group=comp.arch#16188).

I have also seen a posting analysing Intel's patent on alias
prediction and how actual Intel CPUs perform (they implement pretty
accurately what was patented).

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

Following this discussion, it seems that a great deal of thought
needs to go into avoiding Spectre, and people have not yet put
a Spectre-immune CPU on the market.

Could an alternative be memory encryption? IBM has it for zSystem,
but to be useful against spectre, it would have to be included
in the data path between the L1 cache and the rest of the CPU.
If one used AES, the minimum number of xors there is 11, so it
would probably add one cycle of latency.

Probably too expensive...

MitchAlsup <MitchAlsup@aol.com> writes:
>What is the world going to do is x86, ARM, and RISC-V all fail to have=20
>immunity from Spectr=C3=A9 ?

What they have done up to now: Mostly nothing; a few select pieces of
software are considered so relevant that they get Spectre mitigations,
but of course there is no way to know whether they caught everything
(and of course the rest of the software stack is still vulnerable);
and yet even these mitigations often cost more in performance than the
3% Michael S is unwilling to pay for Spectre-immune CPUs
<https://www.phoronix.com/scan.php?page=article&item=spectre-meltdown-2>.

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

Thomas Koenig <tkoenig@netcologne.de> writes:
>Could an alternative be memory encryption?

No. In a Spectre attack the attacked process reads the memory
(speculatively), and it will decrypt it speculatively, and then side
channels are used to extract this information; in the first variants
the side channel was cache accesses, which revealed the address
accessed by the attacked process.

So you may be able to mitigate some kinds of attacks by encrypting the
address, but this won't help against attacks where the side channel
does not use addresses (but, e.g., the power state of the high half of
the AVX units).

>IBM has it for zSystem,
>but to be useful against spectre, it would have to be included
>in the data path between the L1 cache and the rest of the CPU.
>If one used AES, the minimum number of xors there is 11, so it
>would probably add one cycle of latency.

For encrypting L1 caches, it may be better to have some cheap
encryption with very frequent change of keys.

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

Anton Ertl wrote:
> The existing workaround (that does not need additional instructions)
> is to squash an out-of-bounds index to an in-bounds value with an
> instruction like AND or CMOV that we expect to use just data flow, not
> any prediction; this works around Spectre V1. The bounds check for
> the throw is done mostly separately.

That's one way to handle it: Allocate one extra element for all arrays
(located at index -1) and then use code like this

cmp rbx,rdi ; if (idx > limit)
sbb rax,rax ; idx = -1;
or rbx,rbx
mov rax,[rsi+rbx*8] ; return array[idx]

or alternatively, using a static safe/default load address

cmp rbx,rdi
lea rax,[default_value]
lea rbx,[rsi+rbx*8]

cmovc rbx,rax

mov rax,[rbx]

I.e. always load something but use a safe address if the index was out
of range.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Anton Ertl wrote:
>> The existing workaround (that does not need additional instructions)
>> is to squash an out-of-bounds index to an in-bounds value with an
>> instruction like AND or CMOV that we expect to use just data flow, not
>> any prediction; this works around Spectre V1. The bounds check for
>> the throw is done mostly separately.
>
> That's one way to handle it: Allocate one extra element for all arrays
> (located at index -1) and then use code like this
>
> cmp rbx,rdi ; if (idx > limit)
> sbb rax,rax ; idx = -1;
> or rbx,rbx
> mov rax,[rsi+rbx*8] ; return array[idx]
>
> or alternatively, using a static safe/default load address
>
> cmp rbx,rdi
> lea rax,[default_value]
> lea rbx,[rsi+rbx*8]
>
> cmovc rbx,rax
>
> mov rax,[rbx]

Bounds-checking compilers are likely to optimize (where lbound
determines the lower bound and ubound the upper bound)

do i=1,n
call range_check (i,lbound(a,1),ubound(a,1))
a(i) = 0
end do

into

call range_check (1,lbound(a,1),ubound(a,1))
call range_check (n,lbound(a,1),ubound(a,1))

do i=1,n
a(i) = 0
end do

(where one or two of the tests may be elided due to
what is known at comple-time).

Is this also vulnerable to Spectre?

Thomas Koenig <tkoenig@netcologne.de> writes:
>Bounds-checking compilers are likely to optimize (where lbound
>determines the lower bound and ubound the upper bound)
>
> do i=1,n
> call range_check (i,lbound(a,1),ubound(a,1))
> a(i) = 0
> end do
>
>into
>
> call range_check (1,lbound(a,1),ubound(a,1))
> call range_check (n,lbound(a,1),ubound(a,1))
>
> do i=1,n
> a(i) = 0
> end do
>
>(where one or two of the tests may be elided due to
>what is known at comple-time).
>
>Is this also vulnerable to Spectre?

Probably not: While speculative execution will often continue to
speculatively write beyond the end of the array (not commited to
permanent state), I don't see a way to extract information from this
incorrect speculation. However, a loop that reads from a(i) may
reveal the contents of the data beyond a(n) if the right side channel
exists in the code.

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

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Bounds-checking compilers are likely to optimize (where lbound
>>determines the lower bound and ubound the upper bound)
>>
>> do i=1,n
>> call range_check (i,lbound(a,1),ubound(a,1))
>> a(i) = 0
>> end do
>>
>>into
>>
>> call range_check (1,lbound(a,1),ubound(a,1))
>> call range_check (n,lbound(a,1),ubound(a,1))
>>
>> do i=1,n
>> a(i) = 0
>> end do
>>
>>(where one or two of the tests may be elided due to
>>what is known at comple-time).
>>
>>Is this also vulnerable to Spectre?
>
> Probably not: While speculative execution will often continue to
> speculatively write beyond the end of the array (not commited to
> permanent state), I don't see a way to extract information from this
> incorrect speculation. However, a loop that reads from a(i) may
> reveal the contents of the data beyond a(n) if the right side channel
> exists in the code.

Hmm... so what about a "killjoy" instruction which invalidates
all speculatively generated cache entries (or more generally,
speculation state) associated with the current process?

An out-of-bounds array access is an error condition for which the
normal reaction should be process termination. Process termination
will not be predicted well, by definition, and even if it was, I don't
care if it takes 1000 cycles more :-)

On Thursday, March 24, 2022 at 7:18:06 AM UTC-5, Thomas Koenig wrote:
> Terje Mathisen <terje.m...@tmsw.no> schrieb:
> > Anton Ertl wrote:
> >> The existing workaround (that does not need additional instructions)
> >> is to squash an out-of-bounds index to an in-bounds value with an
> >> instruction like AND or CMOV that we expect to use just data flow, not
> >> any prediction; this works around Spectre V1. The bounds check for
> >> the throw is done mostly separately.
> >
> > That's one way to handle it: Allocate one extra element for all arrays
> > (located at index -1) and then use code like this
> >
> > cmp rbx,rdi ; if (idx > limit)
> > sbb rax,rax ; idx = -1;
> > or rbx,rbx
> > mov rax,[rsi+rbx*8] ; return array[idx]
> >
> > or alternatively, using a static safe/default load address
> >
> > cmp rbx,rdi
> > lea rax,[default_value]
> > lea rbx,[rsi+rbx*8]
> >
> > cmovc rbx,rax
> >
> > mov rax,[rbx]
> Bounds-checking compilers are likely to optimize (where lbound
> determines the lower bound and ubound the upper bound)
>
> do i=1,n
> call range_check (i,lbound(a,1),ubound(a,1))
> a(i) = 0
> end do
>
> into
>
> call range_check (1,lbound(a,1),ubound(a,1))
> call range_check (n,lbound(a,1),ubound(a,1))
>
> do i=1,n
> a(i) = 0
> end do
>
> (where one or two of the tests may be elided due to
> what is known at comple-time).
>
> Is this also vulnerable to Spectre?
<
The first Spectré attack front was not an out of bounds access,
but using an in bounds access to access a location in the cache
that this process had not rights to access and THEN using that
to generate a second access which should never have been
performed. So, the above does nothing to mitigate Spectré.
<
We would call this "flying blind"; you can't get the needed information
when the decision was made to access the cache a second time,
and we decided to clean it up between consistent point and retire
point.

On Wednesday, March 23, 2022 at 3:29:44 PM UTC-6, John Dallman wrote:
> In article <20d5ecab-f2ff-4641...@googlegroups.com>,
> jsa...@ecn.ab.ca (Quadibloc) wrote:
>
> > Given that, the way to abolish Spectre for the Android world is
> > clear. Just make a low-power Itanium chip suitable for smartphones.

> Of course, that's a far better idea than the Spectre-invulnerable ARM
> Cortex-A5x CPUs that are used in most low-cost Android devices.

No, I freely admit it isn't; of course those already have the perfect
solution.

However, what about the higher-cost Android devices that use cores that
are vulnerable to Spectre? If Poulson/Kittson is the only possible
high-performance in-order chip, then it's the only alternative there is - one
just has to make a version that can run on batteries.

John Savard

Thomas Koenig <tkoenig@netcologne.de> writes:
>Hmm... so what about a "killjoy" instruction which invalidates
>all speculatively generated cache entries (or more generally,
>speculation state) associated with the current process?

Currently existing CPUs update the cache permanently based on
speculative reads; that's the basis of the cache side channel in
Spectre. There is no way for the microarchitecture to know whether a
cache entry has been updated from a speculatively executed load, much
less whether the speculation was correct or not. But if there was
such a way and such an instruction, it would do nothing against
Spectre, because it does not change the side channel.

Now on a CPU with a Spectre fix along the lines discussed here such an
instruction would be a noop, because a cache line would not reach the
permanent cache before the instruction is committed.

>An out-of-bounds array access is an error condition for which the
>normal reaction should be process termination. Process termination
>will not be predicted well, by definition, and even if it was, I don't
>care if it takes 1000 cycles more :-)

Relevance?

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

On Thursday, March 24, 2022 at 4:24:22 PM UTC+2, Thomas Koenig wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> > Thomas Koenig <tko...@netcologne.de> writes:
> >>Bounds-checking compilers are likely to optimize (where lbound
> >>determines the lower bound and ubound the upper bound)
> >>
> >> do i=1,n
> >> call range_check (i,lbound(a,1),ubound(a,1))
> >> a(i) = 0
> >> end do
> >>
> >>into
> >>
> >> call range_check (1,lbound(a,1),ubound(a,1))
> >> call range_check (n,lbound(a,1),ubound(a,1))
> >>
> >> do i=1,n
> >> a(i) = 0
> >> end do
> >>
> >>(where one or two of the tests may be elided due to
> >>what is known at comple-time).
> >>
> >>Is this also vulnerable to Spectre?
> >
> > Probably not: While speculative execution will often continue to
> > speculatively write beyond the end of the array (not commited to
> > permanent state), I don't see a way to extract information from this
> > incorrect speculation. However, a loop that reads from a(i) may
> > reveal the contents of the data beyond a(n) if the right side channel
> > exists in the code.
> Hmm... so what about a "killjoy" instruction which invalidates
> all speculatively generated cache entries (or more generally,
> speculation state) associated with the current process?
>
> An out-of-bounds array access is an error condition for which the
> normal reaction should be process termination. Process termination
> will not be predicted well, by definition, and even if it was, I don't
> care if it takes 1000 cycles more :-)

I recommend to refresh your memory:
https://spectreattack.com/spectre.pdf

On Thu, 24 Mar 2022, Anton Ertl wrote:

>> Could an alternative be memory encryption?
>
> No. In a Spectre attack the attacked process reads the memory
> (speculatively), and it will decrypt it speculatively

Use a different key for every process. Now when you decrypt it
speculatively, if it wasn't your memory, you get the wrong result.

That doesn't work for shared memory. Are there any other problems? Any
obvious workarounds for shared memory?

On Friday, March 25, 2022 at 1:10:37 PM UTC+3, Elijah Stone wrote:
> On Thu, 24 Mar 2022, Anton Ertl wrote:
>
> >> Could an alternative be memory encryption?
> >
> > No. In a Spectre attack the attacked process reads the memory
> > (speculatively), and it will decrypt it speculatively
> Use a different key for every process. Now when you decrypt it
> speculatively, if it wasn't your memory, you get the wrong result.
>
> That doesn't work for shared memory. Are there any other problems? Any
> obvious workarounds for shared memory?

Spectre-V1 (bound check bypass) is in-process attack.

Elijah Stone <elronnd@elronnd.net> writes:
>On Thu, 24 Mar 2022, Anton Ertl wrote:
>
>>> Could an alternative be memory encryption?
>>
>> No. In a Spectre attack the attacked process reads the memory
>> (speculatively), and it will decrypt it speculatively
>
>Use a different key for every process.

That's what I assumed.

>Now when you decrypt it
>speculatively, if it wasn't your memory, you get the wrong result.

A process normally cannot access other processes memory anyway.

But in Spectre the attacker lets the owning process read the memory.
Therefore encrypting the memory contents won't help.

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

On Friday, March 25, 2022 at 6:28:14 AM UTC-5, Anton Ertl wrote:
> Elijah Stone <elr...@elronnd.net> writes:
> >On Thu, 24 Mar 2022, Anton Ertl wrote:
> >
> >>> Could an alternative be memory encryption?
> >>
> >> No. In a Spectre attack the attacked process reads the memory
> >> (speculatively), and it will decrypt it speculatively
> >
> >Use a different key for every process.
> That's what I assumed.
> >Now when you decrypt it
> >speculatively, if it wasn't your memory, you get the wrong result.
> A process normally cannot access other processes memory anyway.
>
> But in Spectre the attacker lets the owning process read the memory.
> Therefore encrypting the memory contents won't help.
<
Encryption would have to be present throughout the cache hierarchy.
This would not be good for L1 performance.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Elijah Stone <elronnd@elronnd.net> writes:
>>On Thu, 24 Mar 2022, Anton Ertl wrote:
>>
>>>> Could an alternative be memory encryption?
>>>
>>> No. In a Spectre attack the attacked process reads the memory
>>> (speculatively), and it will decrypt it speculatively
>>
>>Use a different key for every process.
>
> That's what I assumed.
>
>>Now when you decrypt it
>>speculatively, if it wasn't your memory, you get the wrong result.
>
> A process normally cannot access other processes memory anyway.
>
> But in Spectre the attacker lets the owning process read the memory.
> Therefore encrypting the memory contents won't help.

If it still was encrypted while in L1, that would not help?

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Elijah Stone <elronnd@elronnd.net> writes:
>>>On Thu, 24 Mar 2022, Anton Ertl wrote:
>>>
>>>>> Could an alternative be memory encryption?
>>>>
>>>> No. In a Spectre attack the attacked process reads the memory
>>>> (speculatively), and it will decrypt it speculatively
>>>
>>>Use a different key for every process.
>>
>> That's what I assumed.
>>
>>>Now when you decrypt it
>>>speculatively, if it wasn't your memory, you get the wrong result.
>>
>> A process normally cannot access other processes memory anyway.
>>
>> But in Spectre the attacker lets the owning process read the memory.
>> Therefore encrypting the memory contents won't help.
>
>If it still was encrypted while in L1, that would not help?

No.

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