Forget about C++, C is not a low-level language either

[Paavo Helde]

Stumbled upon an interesting article by by David Chisnall claiming that
Spectre, Meltdown et al have become possible because of the desire to
let the C programmers to continue to falsely believe they are
programming in a low-level language. I think this is relevant to C++ as
well as the discussed compiler optimizations machinery is the same and
even more important in C++.

https://queue.acm.org/detail.cfm?id=3212479

[Scott Lurndal]

Spectre, Meltdown are simply microarchitectural bugs. Speculative
execution should never cause detectable effects, particularly over
privilege boundaries.

[David Brown]

That's the theory. In practice, it's hard to avoid any possibility of
cross-over. As long as you have a target of doing things as fast as you
can, there will /always/ be timing attacks. The aim should /not/ be to
eliminate detectable effects from speculative execution - the aim should
be to reduce the signal, and increase the noise, until it becomes
impractical to use as an attack vector. The same applies to other types
of cache, other sources of timing differences, and any other kind of
indirect information (cpu die temperature, power usage, etc.). Security
is all about reducing the risk until it is no longer cost-effective to
use that vulnerability - it is never about trying to eliminate the risk.

For some cpus, these particular bugs are far too easy to exploit. By
disallowing speculation across privilege boundaries, you greatly reduce
the risk with only a small cost to performance. To get completely free
of risk, however, you need to have deterministic memory - no
speculation, no caches, etc. And that is not going to happen for
general-purpose cpus.

[Juha Nieminen]

Paavo Helde <myfir...@osa.pri.ee> wrote:
> Stumbled upon an interesting article by by David Chisnall claiming that
> Spectre, Meltdown et al have become possible because of the desire to
> let the C programmers to continue to falsely believe they are
> programming in a low-level language.

That sounds like the most insane non-sequitur ever. Do I even want to
read that article?

[Paavo Helde]

I don't really agree with the author's claim but he has some point and I
found the article quite interesting.

[Melzzzzz]

Whole article has false premise that CPU's are designed to accommodate
C... spectre and meltdown does not have to do anything with C.

>


--
press any key to continue or any other to quit...

[Scott Lurndal]

No. His basic premise (that Spectre/Meltdown have anything to do with
C) is wrong.

[Marcel Mueller]

On 24.05.18 14.54, Scott Lurndal wrote:
> Spectre, Meltdown are simply microarchitectural bugs. Speculative
> execution should never cause detectable effects, particularly over
> privilege boundaries.

It is almost impossible to prevent side channel attacks completely.
/This/ type of attacks might be fixed at some time but others will
arise. Maybe someone detects EM emissions using the built in magnetic
compass sensor, maybe the embedded sensors of modern power supplies
compromises encryption algorithms, maybe something completely different,
but it is pretty sure that there always will be successful side channel
attacks.

Part of the story is the performance overkill of many devices. It makes
it possible to detect even information with a very bad SNR just by using
many repetitions. This applies for instance to row hammer as well as to
Spectre.


Marcel

[Vir Campestris]

On 25/05/2018 16:05, Scott Lurndal wrote:
> No. His basic premise (that Spectre/Meltdown have anything to do with
> C) is wrong.

His basic premise is that C encourages single threaded programming.
(which is of course true of most languages, and I think all of that
vintage).

Given that there will not be many threads each individual thread must
run at the highest possible speed. Which requires caches, pipelines, and
all that gubbins, which is where the side channel attacks come in.

Only trouble is I've only worked on one processor which isn't like that.
SIMD, multiple threads. And a pipeline (though much shorter) and a cache
(which apart from anything works because of locality of reference, which
is nothing to do with single threaded languages).

Thing is though - if you've had an exception trying to access a kernel
page - why not flush the cache? It won't happen often, and bye-bye all
that side channel stuff.

Andy

[Melzzzzz]

On 2018-05-25, Vir Campestris <vir.cam...@invalid.invalid> wrote:
> On 25/05/2018 16:05, Scott Lurndal wrote:
>> No. His basic premise (that Spectre/Meltdown have anything to do with
>> C) is wrong.
>
> His basic premise is that C encourages single threaded programming.

That is wrong, too.

> (which is of course true of most languages, and I think all of that
> vintage).
>
> Given that there will not be many threads each individual thread must
> run at the highest possible speed. Which requires caches, pipelines, and
> all that gubbins, which is where the side channel attacks come in.

This is funny. CPU is designed to run as fast as possible i no matter
language. More so for slow and bloated languages then C.

[Chris Ahlstrom]

Melzzzzz wrote this copyrighted missive and expects royalties:

C was designed to accomodate the PDP-11 (I think) instruction set.

--
Q: Why should you always serve a Southern Carolina football man
soup in a plate?
A: 'Cause if you give him a bowl, he'll throw it away.

[Scott Lurndal]

flushing the cache is a side effect of the exception, thus a covert
channel - useful to determine valid kernel addresses, for example.

[Juha Nieminen]

Vir Campestris <vir.cam...@invalid.invalid> wrote:
> On 25/05/2018 16:05, Scott Lurndal wrote:
>> No. His basic premise (that Spectre/Meltdown have anything to do with
>> C) is wrong.
>
> His basic premise is that C encourages single threaded programming.
> (which is of course true of most languages, and I think all of that
> vintage).
>
> Given that there will not be many threads each individual thread must
> run at the highest possible speed. Which requires caches, pipelines, and
> all that gubbins, which is where the side channel attacks come in.

You seem to be implying that without C we would nowadays have really
slow-ass CPUs that might be able to run thousands of simultaneous
threads, but run each one at a snail's pace (ie. we would still
be in the days when a single register assignment would take at
least 3 or 4 clock cycles, with more complex opcodes taking a dozen).

If that's really the argument, then perhaps C did some good to CPU
design after all. (Not that I believe any of this to be the case,
but assuming if.)

[Vir Campestris]

On 25/05/2018 22:30, Scott Lurndal wrote:
> Vir Campestris <vir.cam...@invalid.invalid> writes:
<snip>

>> Only trouble is I've only worked on one processor which isn't like that.
>> SIMD, multiple threads. And a pipeline (though much shorter) and a cache
>> (which apart from anything works because of locality of reference, which
>> is nothing to do with single threaded languages).
>>
>> Thing is though - if you've had an exception trying to access a kernel
>> page - why not flush the cache? It won't happen often, and bye-bye all
>> that side channel stuff.
>
> flushing the cache is a side effect of the exception, thus a covert
> channel - useful to determine valid kernel addresses, for example.
>

You get an exception when you access a page that you're not allowed to.

System flushes the cache.

There is no way to determine whether this is an illegal address, or a
forbidden address - unless of course the system chooses to tell you.

What will you do with the list of valid kernel addresses anyway? It's
their contents that are interesting.

Andy

[Vir Campestris]

On 27/05/2018 12:20, Juha Nieminen wrote:
> Vir Campestris <vir.cam...@invalid.invalid> wrote:
>> On 25/05/2018 16:05, Scott Lurndal wrote:
>>> No. His basic premise (that Spectre/Meltdown have anything to do with
>>> C) is wrong.
>>
>> His basic premise is that C encourages single threaded programming.
>> (which is of course true of most languages, and I think all of that
>> vintage).
>>
>> Given that there will not be many threads each individual thread must
>> run at the highest possible speed. Which requires caches, pipelines, and
>> all that gubbins, which is where the side channel attacks come in.
>
> You seem to be implying that without C we would nowadays have really
> slow-ass CPUs that might be able to run thousands of simultaneous
> threads, but run each one at a snail's pace (ie. we would still
> be in the days when a single register assignment would take at
> least 3 or 4 clock cycles, with more complex opcodes taking a dozen).
>

Without C, yes. Or Fortran, Cobol, Algol... maybe APL would like a
properly parallel machine, but I can't think of another language of that
vintage that isn't essentially single threaded.

> If that's really the argument, then perhaps C did some good to CPU
> design after all. (Not that I believe any of this to be the case,
> but assuming if.)
>

Andy

[Scott Lurndal]

Vir Campestris <vir.cam...@invalid.invalid> writes:
>On 25/05/2018 22:30, Scott Lurndal wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
><snip>
>>> Only trouble is I've only worked on one processor which isn't like that.
>>> SIMD, multiple threads. And a pipeline (though much shorter) and a cache
>>> (which apart from anything works because of locality of reference, which
>>> is nothing to do with single threaded languages).
>>>
>>> Thing is though - if you've had an exception trying to access a kernel
>>> page - why not flush the cache? It won't happen often, and bye-bye all
>>> that side channel stuff.
>>
>> flushing the cache is a side effect of the exception, thus a covert
>> channel - useful to determine valid kernel addresses, for example.
>>
>You get an exception when you access a page that you're not allowed to.

Which, of course, takes longer than an access that doesn't get
an exception. Covert channel #1.

>
>System flushes the cache.

Which, of course, changes the timing of the code that executes following
the flush. Covert channel #2.

>
>There is no way to determine whether this is an illegal address, or a
>forbidden address - unless of course the system chooses to tell you.

Doesn't matter. It's information that can be used.

>
>What will you do with the list of valid kernel addresses anyway? It's
>their contents that are interesting.

What the list of valid kernel addresses provides is information. Useful
information to those attempting to subvert the kernel; and certainly
key to the exploits enabled by Spectre/Meltdown. Amongst other things,
it allows the attacker to subvert KASLR.

[Robert Wessel]

On Sun, 27 May 2018 21:26:15 +0100, Vir Campestris

<vir.cam...@invalid.invalid> wrote:

>On 27/05/2018 12:20, Juha Nieminen wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> wrote:
>>> On 25/05/2018 16:05, Scott Lurndal wrote:
>>>> No. His basic premise (that Spectre/Meltdown have anything to do with
>>>> C) is wrong.
>>>
>>> His basic premise is that C encourages single threaded programming.
>>> (which is of course true of most languages, and I think all of that
>>> vintage).
>>>
>>> Given that there will not be many threads each individual thread must
>>> run at the highest possible speed. Which requires caches, pipelines, and
>>> all that gubbins, which is where the side channel attacks come in.
>>
>> You seem to be implying that without C we would nowadays have really
>> slow-ass CPUs that might be able to run thousands of simultaneous
>> threads, but run each one at a snail's pace (ie. we would still
>> be in the days when a single register assignment would take at
>> least 3 or 4 clock cycles, with more complex opcodes taking a dozen).
>>
>Without C, yes. Or Fortran, Cobol, Algol... maybe APL would like a
>properly parallel machine, but I can't think of another language of that
>vintage that isn't essentially single threaded.

IBM's PL/1 supporting threading (with a fork/join sort of mechanism on
subroutine calls) in 1966 (and still does), although that was not a
feature that made it into the standard.

[Vir Campestris]

On 28/05/2018 14:23, Scott Lurndal wrote:
> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> On 25/05/2018 22:30, Scott Lurndal wrote:
>>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>> <snip>
>>>> Only trouble is I've only worked on one processor which isn't like that.
>>>> SIMD, multiple threads. And a pipeline (though much shorter) and a cache
>>>> (which apart from anything works because of locality of reference, which
>>>> is nothing to do with single threaded languages).
>>>>
>>>> Thing is though - if you've had an exception trying to access a kernel
>>>> page - why not flush the cache? It won't happen often, and bye-bye all
>>>> that side channel stuff.
>>>
>>> flushing the cache is a side effect of the exception, thus a covert
>>> channel - useful to determine valid kernel addresses, for example.
>>>
>> You get an exception when you access a page that you're not allowed to.
>
> Which, of course, takes longer than an access that doesn't get
> an exception. Covert channel #1.
>

I pick an address that might be a kernel address, and might be an
invalid address. CPU traps out to privileged code, and says to the
kernel "What do I do now?" Privileged code fiddles around for a while,
then passes control to the exception handler in the naughty program.
This will take quite a long time. IF you're really concerned about
security your kernel will make sure it's a _loooooong_ time.

Obviously in either case this will take much longer than accessing an
address to which the program has access. But the times for the two cases
need not be significantly different.

>>
>> System flushes the cache.
>
> Which, of course, changes the timing of the code that executes following
> the flush. Covert channel #2.
>

Yes. But since the app has been given an exception it _knows_ it wasn't
allowed to access the address. And it will soon realise the cache is
empty (if it is that way inclined) because everything will be slow for a
while.

>>
>> There is no way to determine whether this is an illegal address, or a
>> forbidden address - unless of course the system chooses to tell you.
>
> Doesn't matter. It's information that can be used.
>

There is no difference between the exception code nor the timing between
an illegal access fault for an invalid address, and an address which is
merely invalid for that privilege level. There is no information to use.

>>
>> What will you do with the list of valid kernel addresses anyway? It's
>> their contents that are interesting.
>
> What the list of valid kernel addresses provides is information. Useful
> information to those attempting to subvert the kernel; and certainly
> key to the exploits enabled by Spectre/Meltdown. Amongst other things,
> it allows the attacker to subvert KASLR.
>

OK, good point there. I still don't see how you get to differentiate the
two cases.

Andy

[Scott Lurndal]

Vir Campestris <vir.cam...@invalid.invalid> writes:
>On 28/05/2018 14:23, Scott Lurndal wrote:
>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>>> On 25/05/2018 22:30, Scott Lurndal wrote:
>>>> Vir Campestris <vir.cam...@invalid.invalid> writes:
>>> <snip>
>>>>> Only trouble is I've only worked on one processor which isn't like that.
>>>>> SIMD, multiple threads. And a pipeline (though much shorter) and a cache
>>>>> (which apart from anything works because of locality of reference, which
>>>>> is nothing to do with single threaded languages).
>>>>>
>>>>> Thing is though - if you've had an exception trying to access a kernel
>>>>> page - why not flush the cache? It won't happen often, and bye-bye all
>>>>> that side channel stuff.
>>>>
>>>> flushing the cache is a side effect of the exception, thus a covert
>>>> channel - useful to determine valid kernel addresses, for example.
>>>>
>>> You get an exception when you access a page that you're not allowed to.
>>
>> Which, of course, takes longer than an access that doesn't get
>> an exception. Covert channel #1.
>>
>I pick an address that might be a kernel address, and might be an
>invalid address. CPU traps out to privileged code, and says to the
>kernel "What do I do now?" Privileged code fiddles around for a while,
>then passes control to the exception handler in the naughty program.
>This will take quite a long time. IF you're really concerned about
>security your kernel will make sure it's a _loooooong_ time.

I don't have a lot of time to respond to this, but if you google search for

"timewarp: rethinking timekeeping and performance monitoring mechanisms to mitigate
side-channel attacks"

There are descriptions of and references to the various side-channel
attacks via cache timing et alia in that paper.

[Vir Campestris]

This paper?

<http://www.cs.columbia.edu/~simha/preprint_isca12_tw.pdf>

That's a much more complete solution to a much wider range of problems,
but one that requires that the CPU is modified.

As they say you can't afford to cache flush on every context switch.
There's also no way to flush the branch predictor cache (which I'd
forgotten about TBH) but for the class of attacks which rely on the
pipeline pre-fetching stuff to which the program has no right of access,
which causes detectable changes in the cache, clearing the cache ought
to destroy all that side channel data. Leaving only the branch predictor
(which someone will of course use...)

I also feel that killing the process after a few exceptions would be a
good thing to do. Though no doubt there will be a way around that too.

After an exception for an illegal access the state of the cache (and the
branch predictor cache) will be different depending on whether the page
accessed did not exist or was blocked, and also depending on the
contents of that page.

The attacks I have read about rely on detecting the state of the cache
after the exception.

Flushing the cache after such an exception and before returning control
to the user program will destroy that information in the cache.

I do not see that such a change would be harmful, and it would block one
class of attacks.

Andy