linux-kernel - Re: [PATCH v6 00/16] x86/mtrr: fix handling with PAT but without MTRR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e824a95-6676-9553-4158-d434f617fcbb@suse.com>
Date:   Wed, 31 May 2023 11:31:37 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-hyperv@...r.kernel.org, linux-doc@...r.kernel.org,
        mikelley@...rosoft.com, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        xen-devel@...ts.xenproject.org, Jonathan Corbet <corbet@....net>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v6 00/16] x86/mtrr: fix handling with PAT but without MTRR

On 31.05.23 10:35, Borislav Petkov wrote:
> On Wed, May 31, 2023 at 09:28:57AM +0200, Juergen Gross wrote:
>> Can you please boot the system with the MTRR patches and specify "mtrr=debug"
>> on the command line? I'd be interested in the raw register values being read
>> and the resulting memory type map.
> 
> This is exactly why I wanted this option. And you're already putting it
> to good use. :-P
> 
> Full dmesg below.
> 
> [    0.012878] last_pfn = 0x450000 max_arch_pfn = 0x400000000
> [    0.018357] MTRR default type: uncachable
> [    0.022347] MTRR fixed ranges enabled:
> [    0.026085]   00000-9FFFF write-back
> [    0.029650]   A0000-BFFFF uncachable
> [    0.033214]   C0000-FFFFF write-protect
> [    0.037039] MTRR variable ranges enabled:
> [    0.041038]   0 base 000000000000000 mask 0003FFC00000000 write-back

16 GB WB at address 0.

> [    0.047383]   1 base 000000400000000 mask 0003FFFC0000000 write-back

1 GB WB at address 16GB.

> [    0.053730]   2 base 000000440000000 mask 0003FFFF0000000 write-back

256MB WB at address 17GB.

This means per default 0-44fffffff are WB.

> [    0.060076]   3 base 0000000AE000000 mask 0003FFFFE000000 uncachable

32MB UC at AE000000

> [    0.066421]   4 base 0000000B0000000 mask 0003FFFF0000000 uncachable

256MB UC at B0000000

> [    0.072768]   5 base 0000000C0000000 mask 0003FFFC0000000 uncachable

512MB UC at C0000000

So an UC hole at AE000000-FFFFFFFF.

> [    0.079114]   6 disabled
> [    0.081635]   7 disabled
> [    0.084156]   8 disabled
> [    0.086677]   9 disabled
> [    0.089203] total RAM covered: 16352M
> [    0.093023] Found optimal setting for mtrr clean up

It seems as if mtrr_cleanup() did change the MTRR settings.

What it did would have been printed if pr_debug() would have been
active. :-(

> [    0.097734]  gran_size: 64K 	chunk_size: 64M 	num_reg: 8  	lose cover RAM: 0G
> [    0.104864] MTRR map: 6 entries (3 fixed + 3 variable; max 23), built from 10 variable MTRRs
> [    0.113294]   0: 0000000000000000-000000000009ffff write-back
> [    0.119033]   1: 00000000000a0000-00000000000bffff uncachable
> [    0.124771]   2: 00000000000c0000-00000000000fffff write-protect
> [    0.130769]   3: 0000000000100000-00000000adffffff write-back
> [    0.136508]   4: 00000000ae000000-00000000afffffff uncachable
> [    0.142246]   5: 0000000100000000-000000044fffffff write-back

The MTRR map seems to be fine assuming the MTRR values before the "clean up".

> [    0.147992] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
 > [    0.155122] e820: update [mem 0xae000000-0xafffffff] usable ==> reserved
 > [    0.161663] e820: update [mem 0xc0000000-0xffffffff] usable ==> reserved
 > [    0.168358] e820: update [mem 0x110000000-0x1ffffffff] usable ==> reserved
 > [    0.175227] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 
3840MB of RAM.

Clean up messed with the settings, resulting in loss of RAM.

Did you check whether CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT was the same in both
kernels you've tested?


Juergen

Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)