lkml.org 
[lkml]   [2019]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [FYI PATCH 0/7] Mitigation for CVE-2018-12207
From
Date


> 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
\
 
 \ /
  Last update: 2019-11-14 07:02    [W:0.060 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site