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: <1cfde4bf-241f-d94c-ffd7-2a11cf9aa1f2@suse.com>
Date:   Mon, 20 Jun 2022 12:41:45 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     xen-devel@...ts.xenproject.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, jbeulich@...e.com,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 1/2] x86/pat: fix x86_has_pat_wp()

On 20.06.22 12:26, Borislav Petkov wrote:
> On Tue, May 03, 2022 at 03:22:06PM +0200, Juergen Gross wrote:
>> x86_has_pat_wp() is using a wrong test, as it relies on the normal
>> PAT configuration used by the kernel. In case the PAT MSR has been
>> setup by another entity (e.g. BIOS or Xen hypervisor) it might return
>> false even if the PAT configuration is allowing WP mappings.
>>
>> Fixes: 1f6f655e01ad ("x86/mm: Add a x86_has_pat_wp() helper")
>> Signed-off-by: Juergen Gross <jgross@...e.com>
>> ---
>>   arch/x86/mm/init.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
>> index d8cfce221275..71e182ebced3 100644
>> --- a/arch/x86/mm/init.c
>> +++ b/arch/x86/mm/init.c
>> @@ -80,7 +80,8 @@ static uint8_t __pte2cachemode_tbl[8] = {
>>   /* Check that the write-protect PAT entry is set for write-protect */
>>   bool x86_has_pat_wp(void)
>>   {
>> -	return __pte2cachemode_tbl[_PAGE_CACHE_MODE_WP] == _PAGE_CACHE_MODE_WP;
>> +	return __pte2cachemode_tbl[__cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]] ==
>> +	       _PAGE_CACHE_MODE_WP;
> 
> So this code always makes my head spin... especially after vacation but
> lemme take a stab:
> 
> __pte2cachemode_tbl indices are of type enum page_cache_mode.

Yes.

> What you've done is index with
> 
> __cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]
> 
> which gives uint16_t.
> 
> So, if at all, this should do __pte2cm_idx(_PAGE_CACHE_MODE_WP) to index
> into it.

Oh, you are partially right.

It should be __pte2cm_idx(__cachemode2pte_tbl[_PAGE_CACHE_MODE_WP]).

> But I'm still unclear on the big picture. Looking at Jan's explanation,
> there's something about PAT init being skipped due to MTRRs not being
> emulated by Xen.... or something to that effect.

PAT init is being skipped for Xen PV guests, as those can't write the
PAT MSR. They need to cope with the setting the hypervisor has done
(which contains all caching modes, but in a different layout than the
kernel is using normally).

> So if that's the case, the Xen guest code should init PAT in its own
> way, so that the generic code works with this without doing hacks.

Depends on what you mean with "init PAT". If you mean to write the
PAT MSR, then no, this won't work. If you mean to setup the translation
arrays __cachemode2pte_tbl[] and __pte2cachemode_tbl[], then yes, this
is already done.

My patch is only fixing the wrong way querying for WP being supported.

> But I'm only guessing - this needs a *lot* more elaboration and
> explanation why exactly this is needed.

I will correct the code and update the commit message.


Juergen

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ