Messages in this thread | | | Subject | Re: [FYI PATCH 0/7] Mitigation for CVE-2018-12207 | From | Nadav Amit <> | Date | Wed, 13 Nov 2019 22:02:00 -0800 |
| |
> On Nov 13, 2019, at 9:26 PM, Dave Hansen <dave.hansen@intel.com> wrote: > > On 11/13/19 5:17 PM, Nadav Amit wrote: >> But is it always the case? Looking at __split_large_page(), it seems that the >> TLB invalidation is only done after the PMD is changed. Can't this leave a >> small time window in which a malicious actor triggers a machine-check on >> another core than the one that runs __split_large_page()? > > It's not just a split. It has to be a change that results in > inconsistencies between two entries in the TLB. A normal split doesn't > change the resulting final translations and is never inconsistent > between the two translations. > > To have an inconsistency, you need to change the backing physical > address (or cache attributes?). I'd need to go double-check the erratum > to be sure about the cache attributes. > > In any case, that's why we decided that normal kernel mapping > split/merges don't need to be mitigated. But, we should probably > document this somewhere if it's not clear. > > Pawan, did we document the results of the audit you did anywhere?
Thank you for explaining. I now see that it is clearly written:
"Software modifies the paging structures so that the same linear address is translated using a large page (2 MB, 4 MB, or 1 GB) with a different physical address or memory type.” [1]
My bad.
[1] https://software.intel.com/security-software-guidance/insights/deep-dive-machine-check-error-avoidance-page-size-change-0
| |