| 1 |
On Thu, Jan 4, 2018 at 10:18 AM, Rich Freeman <rich0@g.o> wrote: |
| 2 |
> On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1 <r030t1@×××××.com> wrote: |
| 3 |
>> |
| 4 |
>> I am still working through the information myself, but it looks like |
| 5 |
>> BPF filters are an easy way to make sure you have something to look |
| 6 |
>> for in kernelspace. |
| 7 |
> |
| 8 |
> My understanding is that for exploit 1 to work you need to have the |
| 9 |
> kernel execute some code for you, and BPF is a way to do that because |
| 10 |
> it is a JIT compiler. |
| 11 |
> |
| 12 |
> The bits about finding where BPF is in kernelspace is for exploit 2, |
| 13 |
> which requires branching into that code, which requires knowing its |
| 14 |
> address. |
| 15 |
> |
| 16 |
|
| 17 |
What I think is missing is the full details of the cache behavior, |
| 18 |
because I saw some (ad hoc) proposals that the situation may be very, |
| 19 |
very bad indeed. I'll see if I can find the explanation involving only |
| 20 |
usermode code. |
| 21 |
|
| 22 |
The original recommendation from CERT was to fully replace all |
| 23 |
hardware: https://webcache.googleusercontent.com/search?q=cache:rzc6iQmgrIcJ:https://www.kb.cert.org/vuls/id/584653+&cd=4&hl=en&ct=clnk&gl=us |
| 24 |
|
| 25 |
>> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1 <r030t1@×××××.com> wrote: |
| 26 |
>>> But, if they do, |
| 27 |
>> |
| 28 |
>> then AMD processors are susceptible in the same way, and the issue can |
| 29 |
>> not be fixed. There are some news pieces and commenters claiming that |
| 30 |
>> AMD processors suffer similar issues. |
| 31 |
> |
| 32 |
> AMD published this: |
| 33 |
> https://www.amd.com/en/corporate/speculative-execution |
| 34 |
> |
| 35 |
> This tends to go along with Google's statement that AMD is vulnerable |
| 36 |
> to variant 1, but not 2 or 3. |
| 37 |
> |
| 38 |
> There is plenty of speculation going on with the hazy info that was |
| 39 |
> provided, but none of the original sources suggest that AMD is |
| 40 |
> vulnerable to variant 3. For variants 1/2 Google says that AMD is |
| 41 |
> susceptible to only 1, and the white paper says that they're |
| 42 |
> vulnerable to either 1/2 but they don't say which specifically. |
| 43 |
> |
| 44 |
> In any case, short of somebody publishing actual exploit code so that |
| 45 |
> people can run their own tests, I'm going to go with AMD. Nobody |
| 46 |
> reputable is outright contradicting their statements. For variant 1 |
| 47 |
> the only known vulnerability is BPF which probably next to nobody |
| 48 |
> uses, and for variant 2 there really aren't any alternatives available |
| 49 |
> right now anyway. |
| 50 |
> |
| 51 |
|
| 52 |
I think referring to BPF is a red herring, because it is really the |
| 53 |
processor that is at fault. Not BPF. And yes, I'm aware of what AMD |
| 54 |
claims. |
| 55 |
|
| 56 |
Cheers, |
| 57 |
R0b0t1 |
Archives