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 <[email protected]>
---
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;
}
enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
--
2.35.3
Ping?
On 03.05.22 15:22, 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 <[email protected]>
> ---
> 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;
> }
>
> enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
On 03.05.22 15:22, 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 <[email protected]>
> ---
> 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;
> }
>
> enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
x86 maintainers, please consider taking this patch, as it is fixing
a real bug. Patch 2 of this series can be dropped IMO.
Juergen
On 20.06.22 07:22, Thorsten Leemhuis wrote:
> On 14.06.22 17:09, Juergen Gross wrote:
>> On 03.05.22 15:22, 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 <[email protected]>
>>> ---
>>> 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;
>>> }
>>> enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
>>
>> x86 maintainers, please consider taking this patch, as it is fixing
>> a real bug. Patch 2 of this series can be dropped IMO.
>
> Juergen, can you help me out here please. Patch 2 afaics was supposed to
> fix this regression I'm tracking:
> https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
No, patch 2 wasn't covering all needed cases.
> Is Patch 1 alone enough to fix it? Or is there a different fix for it?
Patch 1 is fixing a different issue (it is lacking any maintainer
feedback, though).
This patch of Jan should do the job, but it seems to be stuck, too:
https://lore.kernel.org/lkml/[email protected]/
> Or is there some other solution to finally fix that regressions that
> ideally should have been fixed weeks ago already?
I agree it should have been fixed quite some time now, but the x86
maintainers don't seem to be interested in those stuck patches. :-(
Maybe I should take a different approach:
x86 maintainers, please speak up if you NAK (or Ack) any of above two patches.
In case you don't NAK or take the patches, I'm inclined to carry them via
the Xen tree to get the issues fixed.
Juergen
On 14.06.22 17:09, Juergen Gross wrote:
> On 03.05.22 15:22, 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 <[email protected]>
>> ---
>> 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;
>> }
>> enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
>
> x86 maintainers, please consider taking this patch, as it is fixing
> a real bug. Patch 2 of this series can be dropped IMO.
Juergen, can you help me out here please. Patch 2 afaics was supposed to
fix this regression I'm tracking:
https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
Is Patch 1 alone enough to fix it? Or is there a different fix for it?
Or is there some other solution to finally fix that regressions that
ideally should have been fixed weeks ago already?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.
On 20.06.22 07:30, Juergen Gross wrote:
> On 20.06.22 07:22, Thorsten Leemhuis wrote:
>> On 14.06.22 17:09, Juergen Gross wrote:
>>> On 03.05.22 15:22, 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 <[email protected]>
>>>> ---
>>>> 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;
>>>> }
>>>> enum page_cache_mode pgprot2cachemode(pgprot_t pgprot)
>>>
>>> x86 maintainers, please consider taking this patch, as it is fixing
>>> a real bug. Patch 2 of this series can be dropped IMO.
>>
>> Juergen, can you help me out here please. Patch 2 afaics was supposed to
>> fix this regression I'm tracking:
>> https://lore.kernel.org/regressions/YnHK1Z3o99eMXsVK@mail-itl/
> No, patch 2 wasn't covering all needed cases.
Ahh, happens. Thx for the info.
>> Is Patch 1 alone enough to fix it? Or is there a different fix for it?
> Patch 1 is fixing a different issue (it is lacking any maintainer
> feedback, though).
>
> This patch of Jan should do the job, but it seems to be stuck, too:
> https://lore.kernel.org/lkml/[email protected]/
Ahh. Fun fact: that was on my list of things to prod, too.
>> Or is there some other solution to finally fix that regressions that
>> ideally should have been fixed weeks ago already?
>
> I agree it should have been fixed quite some time now, but the x86
> maintainers don't seem to be interested in those stuck patches. :-(
>
> Maybe I should take a different approach:
>
> x86 maintainers, please speak up if you NAK (or Ack) any of above two
> patches.
> In case you don't NAK or take the patches, I'm inclined to carry them via
> the Xen tree to get the issues fixed.
Yeah, I'd be really glad if we could find a solution for this situation
and get it finally fixed in mainline and backported to stable.
Ciao, Thorsten
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 <[email protected]>
> ---
> 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.
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.
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.
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.
But I'm only guessing - this needs a *lot* more elaboration and
explanation why exactly this is needed.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
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 <[email protected]>
>> ---
>> 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
On 6/20/22 03:41, Juergen Gross wrote:
>> 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.
It would also be great to cover the end-user-visible impact of the bug
and the fix. It _looks_ like it will probably only affect an SEV
system's ability to read some EFI data. That will presumably be pretty
bad because it ends up reading from an encrypted mapping instead of a
decrypted one.
The
pr_warn("failed to early memremap...
is (counterintuitively) what is wanted here.
Right?
On 20.06.22 17:27, Dave Hansen wrote:
> On 6/20/22 03:41, Juergen Gross wrote:
>>> 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.
>
> It would also be great to cover the end-user-visible impact of the bug
> and the fix. It _looks_ like it will probably only affect an SEV
> system's ability to read some EFI data. That will presumably be pretty
> bad because it ends up reading from an encrypted mapping instead of a
> decrypted one.
Xen doesn't support SEV guests yet. So the only caveat here would be EFI
setting up PAT by itself.
Not sure this is really a real world issue.
Juergen