|
Last change
on this file since 109090 was 109090, checked in by vboxsync, 10 days ago |
|
Docs: bugref:10705. The following commits from doc's team git repo has been applied:
ae80a681fb1658b2e20ff12a36588811c14dfe67 Updated description of network types
4779d5f23ada981651803eb1ab029ae19f3394db Added - Shared Folders can't be used on Arm VMs running Windows
42ff285f84faa143fc53a3678b1a28a0cae68705 Started minor updates to security section
5bb1fe545161ec7211b842952221dee2021a6645 Fixed spacing
86c3d9a9eb8c807907fe3977b100712d8717a0bb Included Vadim's feedback
4117e15a9d3304ed6f011a45ad3d85b1783248bc Minor updates to security guide
67f46d035bca90c2bd0dc518456b5f4734a8f1da Updates from Vadim
|
-
Property svn:eol-style
set to
native
-
Property svn:keywords
set to
Author Date Id Revision
|
|
File size:
2.2 KB
|
| Line | |
|---|
| 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>This aims at removing potentially sensitive data from the level 1 data cache when running guest code. However, it is made difficult by hyper-threading setups sharing the level 1 cache and thereby potentially letting the other thread in a pair refill the cache with data the user does not want the guest to see. In addition, flushing the level 1 data cache is usually not without performance side effects.</p>
|
|---|
| 8 | <p>Up-to-date CPU microcode is a prerequisite for the cache flushing mitigations. Some host OSes may install these automatically, though it has traditionally been a task best performed by the system firmware. So, please check with your system / mainboard manufacturer for the latest firmware update.</p>
|
|---|
| 9 | <p>We recommend disabling hyper threading on the host. This is traditionally done from the firmware setup, but some OSes also offers ways disable HT. In some cases it may be disabled by default, but please verify as the effectiveness of the mitigation depends on it.</p>
|
|---|
| 10 | <p>The default action taken by VirtualBox is to flush the level 1 data cache when a thread is scheduled to execute guest code, rather than on each VM entry. This reduces the performance impact, while making the assumption that the host OS will not handle security sensitive data from interrupt handlers and similar without taking precautions.</p>
|
|---|
| 11 | <p>A more aggressive flushing option is provided using the <userinput>VBoxManage modifyvm</userinput>
|
|---|
| 12 | <codeph>--l1d-flush-on-vm-entry</codeph> option. When enabled the level 1 data cache will be flushed on every VM entry. The performance impact is greater than with the default option, though this of course depends on the workload. Workloads producing a lot of VM exits (like networking, VGA access, and similiar) will probably be most impacted.</p>
|
|---|
| 13 | <p>For users not concerned by this security issue, the default mitigation can be disabled using the <userinput>VBoxManage modifyvm <varname>name</varname> --l1d-flush-on-sched off</userinput> command.</p>
|
|---|
| 14 | </body>
|
|---|
| 15 |
|
|---|
| 16 | </topic>
|
|---|
Note:
See
TracBrowser
for help on using the repository browser.
