1 |
On 31/01/18 11:48, Taiidan@×××.com wrote: |
2 |
> On 01/31/2018 04:16 AM, Nikos Chantziaras wrote: |
3 |
> |
4 |
>> On 30/01/18 23:43, Rich Freeman wrote: |
5 |
>>> If you had some program that listened on a socket and accepted a |
6 |
>>> length and a string and then did a bounds check using the length, it |
7 |
>>> might be exploitable if a local process could feed it data. Even if |
8 |
>>> the process only listened for outside connections it might be |
9 |
>>> vulnerable if a local process colluded with a remote host to make that |
10 |
>>> connection. |
11 |
>> |
12 |
>> Well, if you're running a local process that is trying to attack you, |
13 |
>> you've been compromised already, imo. |
14 |
>> |
15 |
>> Local processes are always trusted. If Spectre is a vulnerability that |
16 |
>> can be exploited by trusted code, it's not really a vulnerability. |
17 |
>> Trusted code is called "trusted" for a reason. |
18 |
> I wouldn't classify for instance running a multiplayer game in a VM as |
19 |
> "trusted" code, the whole point of hardware virtualization is that you |
20 |
> don't have to trust what is being executed there. |
21 |
> |
22 |
> Not to mention the issue with most websites requiring javascript for no |
23 |
> reason to function properly. |
24 |
|
25 |
Yeah, that's the kind of software that benefits from the Spectre |
26 |
mitigation patches. Like browsers, virtualization or emulation software, |
27 |
the kernel, etc. |
28 |
|
29 |
Rebuilding the whole system with these flags on doesn't sound like a |
30 |
good idea. Now, I don't know if it would hurt anything, but it's not |
31 |
uncommon for build flags to break random stuff. |
32 |
|
33 |
I haven't seen any word from anyone yet as to whether these flags are |
34 |
actually recommended or not on a system-wide basis. The GCC patches were |
35 |
primarily developed for the kernel, but there was no word about whether |
36 |
or not people should build all their software with these flags or not. |
37 |
|
38 |
So my educated guess is: No. Don't do that. If a package is affected, it |
39 |
stands to reason that the upstream of that package would change their |
40 |
build system to use these new flags where needed. |
41 |
|
42 |
But as always: I could be wrong :-) |