rc04

[Roy Bernat]

Hi

What about release rc04? it should be release at 8/1 that was yesterday .

Roy

[Sven Semmler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/09/2018 12:07 AM, Roy Bernat wrote:

> What about release rc04? it should be release at 8/1 that was
> yesterday .

Delayed until the devs have a good workaround for SP1/SP2/Spectre.

/Sven
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlpUXggACgkQ2m4We49U
H7b7cQ/9EC8aSC9vSuTNl0rVHQtK040eZIrg5sKbsXXLjQbOLkwcpXjvWCiukzj1
hXvUgWvJs2JHTPd9s8Yu/8KlE9Maf+UcbKGvwTPVG6c4tNOHGFLt7C0bRjYVeCp5
lW7pnb1e4rYX99aoeX5/SdWaScv6XLbx9CnRSazgBIYJ0WqfseUR8tcAE9HqKCau
aVrBlbSKLMGgWDx3rRGxJaBv6wf70zGi4SPMeCPQOg2vOJIRyDVGDTEz7LDp/NlA
VfU+xy6q7FlKeKfecftygpgqYmpgI4OOtsRE4OA8KQRAe9RTq+M+2/nebB8/I8tv
X6kXe23s/BtD8Me958har4Wd0quioRbS/dIyhmgDpCkrrg7Afzwk+AokqBTqyFhs
u2WZwoZiqRvRhlBqYp8dR076hx9zDNKSijkCcX5hPdLyX5+B39FGRuEJwz0a7G2F
h3dgxdRDIM/hxf5Sp2Y9E+O0GZaeERWo1fBdjxdbSZV/5CJTTdHBJfMhQ4RUt4sv
2v7/hlgFAhgSvzfXRxemH8elPERHISQ9j3nlKMsa73pnYWpUqeALVfOINbZE8DrU
54j5NPZOdhSrDaTtoS8hm2bF4+KFFjAw19B8s/HvHlwZ9B5PgFwV3et7fYYDjGrS
k0o3nVqKmsooD+yeR+oU/32qz4E0sOq0AxAS1PplU5Y3aMNiZBY=
=59oT
-----END PGP SIGNATURE-----

[Tim W]

Great time to be using a AMD chipset as they are not effected. Wonder if something like this would have been caught years ago if the microcode was open?

This is a big one in terms of the effects it has when mitigated at the software level. I wonder what the performance hit will be from application of whatever patch route Qubes takes? Projections of 5-30% hit.

As I said Great day for AMD stock LOL

[Roy Bernat]

Dont dance on dead bodies ,

:)

[msg...@gmail.com]

AMD is affected by the SP1/SP2/Spectre as well as Intel and ARM.

[Roy Bernat]

So he can not dance :)

[Steve Coleman]

On 01/09/2018 02:11 AM, Tim W wrote:
> On Tuesday, January 9, 2018 at 1:16:10 AM UTC-5, Sven Semmler wrote:


> Great time to be using a AMD chipset as they are not effected.

Just got back from a small seminar on the topic. All modern processors
with speculative execution units are likely effected by this.

> Wonder if something like this would have been caught years ago if the microcode was open?

It would not make any difference, as a microcode patch is not able to
fix the underlying problems in the architecture. The problem lies in the
kernel memory cache system vs the speculative branch prediction portions
of the CPU, and microcode does not generally coordinate these separate
hardware units.

When you have multiple branches of code independently executing in a
given CPU core the kernel can be tricked into loading kernel memory into
cache, which is then able to be accessed/hammered to copy that data back
out into userspace. I heard one quote that the kernel data can be read
at up to 5 kbits/sec by a carefully constructed application.

Since it takes a locally running application to do this trick the flaw
is disastrous for cloud services. Thus allowing anyone to execute
arbitrary code in your virtualization system could be giving away all
the other VM's secrets. Probably not a problem if you trust the code
you are running on a single user system like Qubes, but even signed code
from your repo should be considered suspect for data exfiltration
purposes with this issue unpatched.

> This is a big one in terms of the effects it has when mitigated at the software level. I wonder what the performance hit will be from application of whatever patch route Qubes takes? Projections of 5-30% hit.
>
> As I said Great day for AMD stock LOL

Not a good day for any CPU vendor as far as I can see, because anything
advanced enough to give good performance via speculative execution now
needs to pull back on the reigns until there is a architectural
solution. Likely the next-gen processors will actually fix it, but that
could take years given the modern development cycle time frames.

There are all kinds of patches being worked on to get around this, but
they all show poor performance. We may see patches with better
performance as time goes on in specific instances, but for right now
"slow", by actually defeating speculative execution, seems to be the
solution.

[Chris Laprise]

From my recollection of AMD statements:

SP1: Very hard to exploit on any CPU

SP2: Much harder to exploit on AMD than Intel

SP3/Meltdown: AMD not affected

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Tim W]

that sounds correct based on what I have read. At first AMD claimed it was not effected but it seems as time went on and it was looked at more carefully that has changed. Still I will take more difficult. As AMD has such a small share of processor space it makes it a lower target sort of how Apple use to be to windows and linux still is although not like it use to be. So really with a qubes WS the main issue would be SP2 mitigation.

Amazing this has been an issue for 10yrs.

[Foppe de Haan]

Even funnier: Intel (as the primary actor) was warned against this back in 1995: https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf