| 1 | <?xml version='1.0' encoding='UTF-8'?>
|
|---|
| 2 | <!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
|
|---|
| 3 | <topic xml:lang="en-us" id="flush-level1-data-cache-mitigation">
|
|---|
| 4 | <title>Flushing the Level 1 Data Cache</title>
|
|---|
| 5 |
|
|---|
| 6 | <body>
|
|---|
| 7 | <p>
|
|---|
| 8 | This aims at removing potentially sensitive data from the
|
|---|
| 9 | level 1 data cache when running guest code. However, it is
|
|---|
| 10 | made difficult by hyper-threading setups sharing the level 1
|
|---|
| 11 | cache and thereby potentially letting the other thread in a
|
|---|
| 12 | pair refill the cache with data the user does not want the
|
|---|
| 13 | guest to see. In addition, flushing the level 1 data cache is
|
|---|
| 14 | usually not without performance side effects.
|
|---|
| 15 | </p>
|
|---|
| 16 | <p>
|
|---|
| 17 | Up to date CPU microcode is a prerequisite for the cache
|
|---|
| 18 | flushing mitigations. Some host OSes may install these
|
|---|
| 19 | automatically, though it has traditionally been a task best
|
|---|
| 20 | performed by the system firmware. So, please check with your
|
|---|
| 21 | system / mainboard manufacturer for the latest firmware
|
|---|
| 22 | update.
|
|---|
| 23 | </p>
|
|---|
| 24 | <p>
|
|---|
| 25 | We recommend disabling hyper threading on the host. This is
|
|---|
| 26 | traditionally done from the firmware setup, but some OSes also
|
|---|
| 27 | offers ways disable HT. In some cases it may be disabled by
|
|---|
| 28 | default, but please verify as the effectiveness of the
|
|---|
| 29 | mitigation depends on it.
|
|---|
| 30 | </p>
|
|---|
| 31 | <p>
|
|---|
| 32 | The default action taken by VirtualBox is to flush the level 1
|
|---|
| 33 | data cache when a thread is scheduled to execute guest code,
|
|---|
| 34 | rather than on each VM entry. This reduces the performance
|
|---|
| 35 | impact, while making the assumption that the host OS will not
|
|---|
| 36 | handle security sensitive data from interrupt handlers and
|
|---|
| 37 | similar without taking precautions.
|
|---|
| 38 | </p>
|
|---|
| 39 | <p>
|
|---|
| 40 | A more aggressive flushing option is provided via the
|
|---|
| 41 | <userinput>VBoxManage modifyvm</userinput>
|
|---|
| 42 | <codeph>--l1d-flush-on-vm-entry</codeph> option. When enabled
|
|---|
| 43 | the level 1 data cache will be flushed on every VM entry. The
|
|---|
| 44 | performance impact is greater than with the default option,
|
|---|
| 45 | though this of course depends on the workload. Workloads
|
|---|
| 46 | producing a lot of VM exits (like networking, VGA access, and
|
|---|
| 47 | similiar) will probably be most impacted.
|
|---|
| 48 | </p>
|
|---|
| 49 | <p>
|
|---|
| 50 | For users not concerned by this security issue, the default
|
|---|
| 51 | mitigation can be disabled using the <userinput>VBoxManage
|
|---|
| 52 | modifyvm <varname>name</varname> --l1d-flush-on-sched off</userinput> command.
|
|---|
| 53 | </p>
|
|---|
| 54 | </body>
|
|---|
| 55 |
|
|---|
| 56 | </topic>
|
|---|
