1 |
On Mon, Jan 29, 2018 at 4:19 AM, Nikos Chantziaras <realnc@×××××.com> wrote: |
2 |
> For this to work, you need to enable CONFIG_RETPOLINE in the kernel: |
3 |
> |
4 |
> Processor type and features |
5 |
> [*] Avoid speculative indirect branches in kernel |
6 |
> |
7 |
|
8 |
Note that in general upstream recommends enabling these protections |
9 |
even if your CPU isn't vulnerable. In general the kernel detects at |
10 |
boot what is needed and they've done some work to try to use the least |
11 |
invasive solution needed for your particular CPU. Then, if you later |
12 |
re-use that config on a vulnerable CPU without thinking about it |
13 |
(perhaps years from now) you won't be left unprotected. |
14 |
|
15 |
The only really expensive mitigation is for Meltdown (PTI) and it is |
16 |
disabled automatically on AMD CPUs. The Retpolines are also adjusted |
17 |
by CPU type. |
18 |
|
19 |
There is talk of allowing KPTI to be disabled per-process in the |
20 |
future, which would be the best of both worlds. If you had a database |
21 |
server you could disable KPTI on the database server process itself |
22 |
(which does effectively give it root access, though only if exploited |
23 |
- it isn't going to accidentally mess things up), but still leave the |
24 |
overall system protected against random processes escalating privs. |
25 |
If you have a dedicated database server then probably the only process |
26 |
you truly worry about is the database server itself, so if something |
27 |
is running malicious code on this process you've already lost whether |
28 |
it has root access or not. Though, I would probably also point out |
29 |
that I would use care applying this to containers and not just to VMs, |
30 |
because the vulnerability would let you cross container boundaries, |
31 |
but not VMs (assuming you haven't enabled similar exceptions to PTI in |
32 |
the hypervisor). |
33 |
|
34 |
|
35 |
-- |
36 |
Rich |