1 |
On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1 <r030t1@×××××.com> wrote: |
2 |
> |
3 |
> I am still working through the information myself, but it looks like |
4 |
> BPF filters are an easy way to make sure you have something to look |
5 |
> for in kernelspace. |
6 |
|
7 |
My understanding is that for exploit 1 to work you need to have the |
8 |
kernel execute some code for you, and BPF is a way to do that because |
9 |
it is a JIT compiler. |
10 |
|
11 |
The bits about finding where BPF is in kernelspace is for exploit 2, |
12 |
which requires branching into that code, which requires knowing its |
13 |
address. |
14 |
|
15 |
> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1 <r030t1@×××××.com> wrote: |
16 |
>> But, if they do, |
17 |
> |
18 |
> then AMD processors are susceptible in the same way, and the issue can |
19 |
> not be fixed. There are some news pieces and commenters claiming that |
20 |
> AMD processors suffer similar issues. |
21 |
|
22 |
AMD published this: |
23 |
https://www.amd.com/en/corporate/speculative-execution |
24 |
|
25 |
This tends to go along with Google's statement that AMD is vulnerable |
26 |
to variant 1, but not 2 or 3. |
27 |
|
28 |
There is plenty of speculation going on with the hazy info that was |
29 |
provided, but none of the original sources suggest that AMD is |
30 |
vulnerable to variant 3. For variants 1/2 Google says that AMD is |
31 |
susceptible to only 1, and the white paper says that they're |
32 |
vulnerable to either 1/2 but they don't say which specifically. |
33 |
|
34 |
In any case, short of somebody publishing actual exploit code so that |
35 |
people can run their own tests, I'm going to go with AMD. Nobody |
36 |
reputable is outright contradicting their statements. For variant 1 |
37 |
the only known vulnerability is BPF which probably next to nobody |
38 |
uses, and for variant 2 there really aren't any alternatives available |
39 |
right now anyway. |
40 |
|
41 |
-- |
42 |
Rich |