Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
在 2018年09月05日 14:46, Dave Young 写道: > [snip] >> >> As previously mentioned, there are also many differences between kexec and >> kdump. In general, >> kexec needs to look at all of available physical memory, but kdump doesn't >> need. >> >> For kexec, kexec-tools will read /sys/firmware/memmap and recreate the e820 >> ranges for the 2nd >> kernel. If it fails, will use /proc/iomem. >> >> For kdump, kexec-tools will read /proc/iomem and recreate the e820 ranges >> for kdump kernel. >> BTW: we can not get the range of persistent memory from /proc/iomem. So e820 >> ranges don't contain >> the persistent memory in kdump kernel, this is the real reason why i need to >> strengthen the logic >> of adjusting memory encryption mask. > > "persistent memory" is different, I think you meant about some reserved > memory instead > >> >> If kexec-tools also use /sys/firmware/memmap for kdump(like kexec), kdump >> kernel can also work >> without a fix, but the kexec-tools will have to be modified. Are you sure >> that you want me to >> fix kexec-tools instead of kernel? > > Yes, please fix kexec-tools to pass reserved ranges in e820, you will > not need this patch then. > This might be a kexec-tools bug, i have posted a patch for kexec-tools(please check ke...@lists.infradead.org). Thanks. > Thanks > Dave > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
[snip] > > As previously mentioned, there are also many differences between kexec and > kdump. In general, > kexec needs to look at all of available physical memory, but kdump doesn't > need. > > For kexec, kexec-tools will read /sys/firmware/memmap and recreate the e820 > ranges for the 2nd > kernel. If it fails, will use /proc/iomem. > > For kdump, kexec-tools will read /proc/iomem and recreate the e820 ranges for > kdump kernel. > BTW: we can not get the range of persistent memory from /proc/iomem. So e820 > ranges don't contain > the persistent memory in kdump kernel, this is the real reason why i need to > strengthen the logic > of adjusting memory encryption mask. "persistent memory" is different, I think you meant about some reserved memory instead > > If kexec-tools also use /sys/firmware/memmap for kdump(like kexec), kdump > kernel can also work > without a fix, but the kexec-tools will have to be modified. Are you sure > that you want me to > fix kexec-tools instead of kernel? Yes, please fix kexec-tools to pass reserved ranges in e820, you will not need this patch then. Thanks Dave ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
在 2018年09月04日 09:51, Dave Young 写道:
> On 09/04/18 at 09:29am, Dave Young wrote:
>> On 09/04/18 at 08:44am, Dave Young wrote:
>>> On 09/03/18 at 10:06pm, lijiang wrote:
在 2018年09月03日 10:45, Dave Young 写道:
> On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
>> For kdump kernel, when SME is enabled, the acpi table and dmi table will
>> need
>> to be remapped without the memory encryption mask. So we have to
>> strengthen
>> the logic in early_memremap_pgprot_adjust(), which makes us have an
>> opportunity
>> to adjust the memory encryption mask.
>>
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/mm/ioremap.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>> index e01e6c695add..f9d9a39955f3 100644
>> --- a/arch/x86/mm/ioremap.c
>> +++ b/arch/x86/mm/ioremap.c
>> @@ -689,8 +689,15 @@ pgprot_t __init
>> early_memremap_pgprot_adjust(resource_size_t phys_addr,
>> encrypted_prot = true;
>>
>> if (sme_active()) {
>> +/*
>> + * In kdump kernel, the acpi table and dmi table will
>> need
>> + * to be remapped without the memory encryption mask.
>> Here
>> + * we have to strengthen the logic to adjust the memory
>> + * encryption mask.
>
> Assume the acpi/dmi tables are identical for both 1st kernel and kdump
> kernel, I'm not sure what is the difference, why need special handling
> for kdump. Can you add more explanations?
>
Ok, i will use a dmi example to explain this issue.
There are significant differences about E820 between the 1st kernel and
kdump kernel. I pasted them at bottom.
Firstly, we need to know how they are called.
__acpi_map_table()\
/ early_memremap_is_setup_data()
|-> early_memremap()-> early_memremap_pgprot_adjust()->
| memremap_is_efi_data()
dmi_early_remap()/
\ memremap_should_map_decrypted()-> e820__get_entry_type()
Secondly, we also need to understand the memremap_should_map_decrypted(),
which is illustrated by the fake code.
static bool memremap_should_map_decrypted(resource_size_t phys_addr,
unsigned long size)
{
/* code ... */
switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
case E820_TYPE_RESERVED:
case E820_TYPE_ACPI:
case E820_TYPE_NVS:
case E820_TYPE_UNUSABLE:
/* For SEV, these areas are encrypted */
if (sev_active())
break;
/* Fallthrough */
case E820_TYPE_PRAM:
/* For SME, these areas are decrypted */
return true;
default:
/* these areas are encrypted by default*/
break;
}
return false;
}
For the dmi case, the dmi base address is 0x6286b000 in my test machine.
In the 1st kernel, the e820__get_entry_type() can get a valid entry and
type by the dmi address, and we can also find the dmi base address from
e820.
(see the 1st kernel log)
0x6286b000 ∈ [mem 0x6286b000-0x6286efff]
So, these areas are decrypted according to the
memremap_should_map_decrypted().
In kdump kernel, the dmi base address is still 0x6286b000, but we can not
find the dmi base address from e820 any more. The e820__get_entry_type()
can
not get a valid entry and type by the dmi base address, it will go into
the default branch. That is to say, these areas become encrypted. In fact,
these
areas are also decrypted, so we have to strengthen the logic of adjusting
the memory encryption mask.
The 1st kernel log:
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008bfff]
usable
[0.00] BIOS-e820: [mem 0x0008c000-0x0009]
reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f]
reserved
[0.00] BIOS-e820: [mem 0x0010-0x29920fff]
usable
[0.00] BIOS-e820: [mem 0x29921000-0x29921fff]
reserved
[0.00] BIOS-e820: [mem 0x29922000-0x62256fff]
usable
[0.00] BIOS-e820: [mem 0x62257000-0x62356fff]
reserved
[0.00] BIOS-e820: [mem 0x62357000-0x6235cfff] ACPI
data
[
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
On 09/04/18 at 09:29am, Dave Young wrote:
> On 09/04/18 at 08:44am, Dave Young wrote:
> > On 09/03/18 at 10:06pm, lijiang wrote:
> > > 在 2018年09月03日 10:45, Dave Young 写道:
> > > > On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> > > >> For kdump kernel, when SME is enabled, the acpi table and dmi table
> > > >> will need
> > > >> to be remapped without the memory encryption mask. So we have to
> > > >> strengthen
> > > >> the logic in early_memremap_pgprot_adjust(), which makes us have an
> > > >> opportunity
> > > >> to adjust the memory encryption mask.
> > > >>
> > > >> Signed-off-by: Lianbo Jiang
> > > >> ---
> > > >> arch/x86/mm/ioremap.c | 9 -
> > > >> 1 file changed, 8 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> > > >> index e01e6c695add..f9d9a39955f3 100644
> > > >> --- a/arch/x86/mm/ioremap.c
> > > >> +++ b/arch/x86/mm/ioremap.c
> > > >> @@ -689,8 +689,15 @@ pgprot_t __init
> > > >> early_memremap_pgprot_adjust(resource_size_t phys_addr,
> > > >>encrypted_prot = true;
> > > >>
> > > >>if (sme_active()) {
> > > >> +/*
> > > >> + * In kdump kernel, the acpi table and dmi table will
> > > >> need
> > > >> + * to be remapped without the memory encryption mask.
> > > >> Here
> > > >> + * we have to strengthen the logic to adjust the
> > > >> memory
> > > >> + * encryption mask.
> > > >
> > > > Assume the acpi/dmi tables are identical for both 1st kernel and kdump
> > > > kernel, I'm not sure what is the difference, why need special handling
> > > > for kdump. Can you add more explanations?
> > > >
> > >
> > > Ok, i will use a dmi example to explain this issue.
> > >
> > > There are significant differences about E820 between the 1st kernel and
> > > kdump kernel. I pasted them at bottom.
> > >
> > > Firstly, we need to know how they are called.
> > > __acpi_map_table()\
> > > / early_memremap_is_setup_data()
> > >|-> early_memremap()->
> > > early_memremap_pgprot_adjust()-> | memremap_is_efi_data()
> > > dmi_early_remap()/
> > > \ memremap_should_map_decrypted()-> e820__get_entry_type()
> > >
> > > Secondly, we also need to understand the memremap_should_map_decrypted(),
> > > which is illustrated by the fake code.
> > > static bool memremap_should_map_decrypted(resource_size_t phys_addr,
> > > unsigned long size)
> > > {
> > >
> > > /* code ... */
> > >
> > > switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
> > > case E820_TYPE_RESERVED:
> > > case E820_TYPE_ACPI:
> > > case E820_TYPE_NVS:
> > > case E820_TYPE_UNUSABLE:
> > > /* For SEV, these areas are encrypted */
> > > if (sev_active())
> > > break;
> > > /* Fallthrough */
> > >
> > > case E820_TYPE_PRAM:
> > > /* For SME, these areas are decrypted */
> > > return true;
> > > default:
> > > /* these areas are encrypted by default*/
> > > break;
> > > }
> > >
> > > return false;
> > > }
> > >
> > > For the dmi case, the dmi base address is 0x6286b000 in my test machine.
> > >
> > > In the 1st kernel, the e820__get_entry_type() can get a valid entry and
> > > type by the dmi address, and we can also find the dmi base address from
> > > e820.
> > > (see the 1st kernel log)
> > > 0x6286b000 ∈ [mem 0x6286b000-0x6286efff]
> > > So, these areas are decrypted according to the
> > > memremap_should_map_decrypted().
> > >
> > > In kdump kernel, the dmi base address is still 0x6286b000, but we can not
> > > find the dmi base address from e820 any more. The e820__get_entry_type()
> > > can
> > > not get a valid entry and type by the dmi base address, it will go into
> > > the default branch. That is to say, these areas become encrypted. In
> > > fact, these
> > > areas are also decrypted, so we have to strengthen the logic of adjusting
> > > the memory encryption mask.
> > >
> > >
> > > The 1st kernel log:
> > >
> > > [0.00] BIOS-provided physical RAM map:
> > > [0.00] BIOS-e820: [mem 0x-0x0008bfff]
> > > usable
> > > [0.00] BIOS-e820: [mem 0x0008c000-0x0009]
> > > reserved
> > > [0.00] BIOS-e820: [mem 0x000e-0x000f]
> > > reserved
> > > [0.00] BIOS-e820: [mem 0x0010-0x29920fff]
> > > usable
> > > [0.00] BIOS-e820: [mem 0x29921000-0x29921fff]
> > > reserved
> > > [0.00] BIOS-e820: [mem 0x29922000-0x62256fff]
> > > usable
> > > [0.00] BIOS-e820: [mem
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
在 2018年09月04日 08:44, Dave Young 写道:
> On 09/03/18 at 10:06pm, lijiang wrote:
>> 在 2018年09月03日 10:45, Dave Young 写道:
>>> On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
For kdump kernel, when SME is enabled, the acpi table and dmi table will
need
to be remapped without the memory encryption mask. So we have to strengthen
the logic in early_memremap_pgprot_adjust(), which makes us have an
opportunity
to adjust the memory encryption mask.
Signed-off-by: Lianbo Jiang
---
arch/x86/mm/ioremap.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index e01e6c695add..f9d9a39955f3 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -689,8 +689,15 @@ pgprot_t __init
early_memremap_pgprot_adjust(resource_size_t phys_addr,
encrypted_prot = true;
if (sme_active()) {
+/*
+ * In kdump kernel, the acpi table and dmi table will need
+ * to be remapped without the memory encryption mask. Here
+ * we have to strengthen the logic to adjust the memory
+ * encryption mask.
>>>
>>> Assume the acpi/dmi tables are identical for both 1st kernel and kdump
>>> kernel, I'm not sure what is the difference, why need special handling
>>> for kdump. Can you add more explanations?
>>>
>>
>> Ok, i will use a dmi example to explain this issue.
>>
>> There are significant differences about E820 between the 1st kernel and
>> kdump kernel. I pasted them at bottom.
>>
>> Firstly, we need to know how they are called.
>> __acpi_map_table()\/
>> early_memremap_is_setup_data()
>>|-> early_memremap()-> early_memremap_pgprot_adjust()-> |
>> memremap_is_efi_data()
>> dmi_early_remap()/\
>> memremap_should_map_decrypted()-> e820__get_entry_type()
>>
>> Secondly, we also need to understand the memremap_should_map_decrypted(),
>> which is illustrated by the fake code.
>> static bool memremap_should_map_decrypted(resource_size_t phys_addr,
>> unsigned long size)
>> {
>>
>> /* code ... */
>>
>> switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
>> case E820_TYPE_RESERVED:
>> case E820_TYPE_ACPI:
>> case E820_TYPE_NVS:
>> case E820_TYPE_UNUSABLE:
>> /* For SEV, these areas are encrypted */
>> if (sev_active())
>> break;
>> /* Fallthrough */
>>
>> case E820_TYPE_PRAM:
>> /* For SME, these areas are decrypted */
>> return true;
>> default:
>> /* these areas are encrypted by default*/
>> break;
>> }
>>
>> return false;
>> }
>>
>> For the dmi case, the dmi base address is 0x6286b000 in my test machine.
>>
>> In the 1st kernel, the e820__get_entry_type() can get a valid entry and type
>> by the dmi address, and we can also find the dmi base address from e820.
>> (see the 1st kernel log)
>> 0x6286b000 ∈ [mem 0x6286b000-0x6286efff]
>> So, these areas are decrypted according to the
>> memremap_should_map_decrypted().
>>
>> In kdump kernel, the dmi base address is still 0x6286b000, but we can not
>> find the dmi base address from e820 any more. The e820__get_entry_type() can
>> not get a valid entry and type by the dmi base address, it will go into the
>> default branch. That is to say, these areas become encrypted. In fact, these
>> areas are also decrypted, so we have to strengthen the logic of adjusting
>> the memory encryption mask.
>>
>>
>> The 1st kernel log:
>>
>> [0.00] BIOS-provided physical RAM map:
>> [0.00] BIOS-e820: [mem 0x-0x0008bfff] usable
>> [0.00] BIOS-e820: [mem 0x0008c000-0x0009]
>> reserved
>> [0.00] BIOS-e820: [mem 0x000e-0x000f]
>> reserved
>> [0.00] BIOS-e820: [mem 0x0010-0x29920fff] usable
>> [0.00] BIOS-e820: [mem 0x29921000-0x29921fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0x29922000-0x62256fff] usable
>> [0.00] BIOS-e820: [mem 0x62257000-0x62356fff]
>> reserved
>> [0.00] BIOS-e820: [mem 0x62357000-0x6235cfff] ACPI
>> data
>> [0.00] BIOS-e820: [mem 0x6235d000-0x623dbfff] usable
>> [0.00] BIOS-e820: [mem 0x623dc000-0x6261bfff]
>> reserved
>> [0.00] BIOS-e820: [mem 0x6261c000-0x6263dfff] usable
>> [0.00] BIOS-e820: [mem 0x6263e000-0x6269dfff]
>> reserved
>> [0.00] BIOS-e820: [mem
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
On 09/04/18 at 08:44am, Dave Young wrote:
> On 09/03/18 at 10:06pm, lijiang wrote:
> > 在 2018年09月03日 10:45, Dave Young 写道:
> > > On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> > >> For kdump kernel, when SME is enabled, the acpi table and dmi table will
> > >> need
> > >> to be remapped without the memory encryption mask. So we have to
> > >> strengthen
> > >> the logic in early_memremap_pgprot_adjust(), which makes us have an
> > >> opportunity
> > >> to adjust the memory encryption mask.
> > >>
> > >> Signed-off-by: Lianbo Jiang
> > >> ---
> > >> arch/x86/mm/ioremap.c | 9 -
> > >> 1 file changed, 8 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> > >> index e01e6c695add..f9d9a39955f3 100644
> > >> --- a/arch/x86/mm/ioremap.c
> > >> +++ b/arch/x86/mm/ioremap.c
> > >> @@ -689,8 +689,15 @@ pgprot_t __init
> > >> early_memremap_pgprot_adjust(resource_size_t phys_addr,
> > >> encrypted_prot = true;
> > >>
> > >> if (sme_active()) {
> > >> +/*
> > >> + * In kdump kernel, the acpi table and dmi table will
> > >> need
> > >> + * to be remapped without the memory encryption mask.
> > >> Here
> > >> + * we have to strengthen the logic to adjust the memory
> > >> + * encryption mask.
> > >
> > > Assume the acpi/dmi tables are identical for both 1st kernel and kdump
> > > kernel, I'm not sure what is the difference, why need special handling
> > > for kdump. Can you add more explanations?
> > >
> >
> > Ok, i will use a dmi example to explain this issue.
> >
> > There are significant differences about E820 between the 1st kernel and
> > kdump kernel. I pasted them at bottom.
> >
> > Firstly, we need to know how they are called.
> > __acpi_map_table()\
> > / early_memremap_is_setup_data()
> >|-> early_memremap()-> early_memremap_pgprot_adjust()->
> > | memremap_is_efi_data()
> > dmi_early_remap()/
> > \ memremap_should_map_decrypted()-> e820__get_entry_type()
> >
> > Secondly, we also need to understand the memremap_should_map_decrypted(),
> > which is illustrated by the fake code.
> > static bool memremap_should_map_decrypted(resource_size_t phys_addr,
> > unsigned long size)
> > {
> >
> > /* code ... */
> >
> > switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
> > case E820_TYPE_RESERVED:
> > case E820_TYPE_ACPI:
> > case E820_TYPE_NVS:
> > case E820_TYPE_UNUSABLE:
> > /* For SEV, these areas are encrypted */
> > if (sev_active())
> > break;
> > /* Fallthrough */
> >
> > case E820_TYPE_PRAM:
> > /* For SME, these areas are decrypted */
> > return true;
> > default:
> > /* these areas are encrypted by default*/
> > break;
> > }
> >
> > return false;
> > }
> >
> > For the dmi case, the dmi base address is 0x6286b000 in my test machine.
> >
> > In the 1st kernel, the e820__get_entry_type() can get a valid entry and
> > type by the dmi address, and we can also find the dmi base address from
> > e820.
> > (see the 1st kernel log)
> > 0x6286b000 ∈ [mem 0x6286b000-0x6286efff]
> > So, these areas are decrypted according to the
> > memremap_should_map_decrypted().
> >
> > In kdump kernel, the dmi base address is still 0x6286b000, but we can not
> > find the dmi base address from e820 any more. The e820__get_entry_type() can
> > not get a valid entry and type by the dmi base address, it will go into the
> > default branch. That is to say, these areas become encrypted. In fact, these
> > areas are also decrypted, so we have to strengthen the logic of adjusting
> > the memory encryption mask.
> >
> >
> > The 1st kernel log:
> >
> > [0.00] BIOS-provided physical RAM map:
> > [0.00] BIOS-e820: [mem 0x-0x0008bfff] usable
> > [0.00] BIOS-e820: [mem 0x0008c000-0x0009]
> > reserved
> > [0.00] BIOS-e820: [mem 0x000e-0x000f]
> > reserved
> > [0.00] BIOS-e820: [mem 0x0010-0x29920fff] usable
> > [0.00] BIOS-e820: [mem 0x29921000-0x29921fff]
> > reserved
> > [0.00] BIOS-e820: [mem 0x29922000-0x62256fff] usable
> > [0.00] BIOS-e820: [mem 0x62257000-0x62356fff]
> > reserved
> > [0.00] BIOS-e820: [mem 0x62357000-0x6235cfff] ACPI
> > data
> > [0.00] BIOS-e820: [mem 0x6235d000-0x623dbfff] usable
> > [0.00] BIOS-e820: [mem 0x623dc000-0x6261bfff]
> > reserved
> > [0.00]
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
On 09/03/18 at 10:06pm, lijiang wrote:
> 在 2018年09月03日 10:45, Dave Young 写道:
> > On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> >> For kdump kernel, when SME is enabled, the acpi table and dmi table will
> >> need
> >> to be remapped without the memory encryption mask. So we have to strengthen
> >> the logic in early_memremap_pgprot_adjust(), which makes us have an
> >> opportunity
> >> to adjust the memory encryption mask.
> >>
> >> Signed-off-by: Lianbo Jiang
> >> ---
> >> arch/x86/mm/ioremap.c | 9 -
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> >> index e01e6c695add..f9d9a39955f3 100644
> >> --- a/arch/x86/mm/ioremap.c
> >> +++ b/arch/x86/mm/ioremap.c
> >> @@ -689,8 +689,15 @@ pgprot_t __init
> >> early_memremap_pgprot_adjust(resource_size_t phys_addr,
> >>encrypted_prot = true;
> >>
> >>if (sme_active()) {
> >> +/*
> >> + * In kdump kernel, the acpi table and dmi table will need
> >> + * to be remapped without the memory encryption mask. Here
> >> + * we have to strengthen the logic to adjust the memory
> >> + * encryption mask.
> >
> > Assume the acpi/dmi tables are identical for both 1st kernel and kdump
> > kernel, I'm not sure what is the difference, why need special handling
> > for kdump. Can you add more explanations?
> >
>
> Ok, i will use a dmi example to explain this issue.
>
> There are significant differences about E820 between the 1st kernel and kdump
> kernel. I pasted them at bottom.
>
> Firstly, we need to know how they are called.
> __acpi_map_table()\/
> early_memremap_is_setup_data()
>|-> early_memremap()-> early_memremap_pgprot_adjust()-> |
> memremap_is_efi_data()
> dmi_early_remap()/\
> memremap_should_map_decrypted()-> e820__get_entry_type()
>
> Secondly, we also need to understand the memremap_should_map_decrypted(),
> which is illustrated by the fake code.
> static bool memremap_should_map_decrypted(resource_size_t phys_addr,
> unsigned long size)
> {
>
> /* code ... */
>
> switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
> case E820_TYPE_RESERVED:
> case E820_TYPE_ACPI:
> case E820_TYPE_NVS:
> case E820_TYPE_UNUSABLE:
> /* For SEV, these areas are encrypted */
> if (sev_active())
> break;
> /* Fallthrough */
>
> case E820_TYPE_PRAM:
> /* For SME, these areas are decrypted */
> return true;
> default:
> /* these areas are encrypted by default*/
> break;
> }
>
> return false;
> }
>
> For the dmi case, the dmi base address is 0x6286b000 in my test machine.
>
> In the 1st kernel, the e820__get_entry_type() can get a valid entry and type
> by the dmi address, and we can also find the dmi base address from e820.
> (see the 1st kernel log)
> 0x6286b000 ∈ [mem 0x6286b000-0x6286efff]
> So, these areas are decrypted according to the
> memremap_should_map_decrypted().
>
> In kdump kernel, the dmi base address is still 0x6286b000, but we can not
> find the dmi base address from e820 any more. The e820__get_entry_type() can
> not get a valid entry and type by the dmi base address, it will go into the
> default branch. That is to say, these areas become encrypted. In fact, these
> areas are also decrypted, so we have to strengthen the logic of adjusting the
> memory encryption mask.
>
>
> The 1st kernel log:
>
> [0.00] BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0008bfff] usable
> [0.00] BIOS-e820: [mem 0x0008c000-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0x29920fff] usable
> [0.00] BIOS-e820: [mem 0x29921000-0x29921fff] reserved
> [0.00] BIOS-e820: [mem 0x29922000-0x62256fff] usable
> [0.00] BIOS-e820: [mem 0x62257000-0x62356fff] reserved
> [0.00] BIOS-e820: [mem 0x62357000-0x6235cfff] ACPI
> data
> [0.00] BIOS-e820: [mem 0x6235d000-0x623dbfff] usable
> [0.00] BIOS-e820: [mem 0x623dc000-0x6261bfff] reserved
> [0.00] BIOS-e820: [mem 0x6261c000-0x6263dfff] usable
> [0.00] BIOS-e820: [mem 0x6263e000-0x6269dfff] reserved
> [0.00] BIOS-e820: [mem 0x6269e000-0x627d6fff] usable
> [0.00] BIOS-e820: [mem 0x627d7000-0x627e3fff] ACPI
> data
> [0.00]
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
在 2018年09月03日 10:45, Dave Young 写道:
> On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
>> For kdump kernel, when SME is enabled, the acpi table and dmi table will need
>> to be remapped without the memory encryption mask. So we have to strengthen
>> the logic in early_memremap_pgprot_adjust(), which makes us have an
>> opportunity
>> to adjust the memory encryption mask.
>>
>> Signed-off-by: Lianbo Jiang
>> ---
>> arch/x86/mm/ioremap.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
>> index e01e6c695add..f9d9a39955f3 100644
>> --- a/arch/x86/mm/ioremap.c
>> +++ b/arch/x86/mm/ioremap.c
>> @@ -689,8 +689,15 @@ pgprot_t __init
>> early_memremap_pgprot_adjust(resource_size_t phys_addr,
>> encrypted_prot = true;
>>
>> if (sme_active()) {
>> +/*
>> + * In kdump kernel, the acpi table and dmi table will need
>> + * to be remapped without the memory encryption mask. Here
>> + * we have to strengthen the logic to adjust the memory
>> + * encryption mask.
>
> Assume the acpi/dmi tables are identical for both 1st kernel and kdump
> kernel, I'm not sure what is the difference, why need special handling
> for kdump. Can you add more explanations?
>
Ok, i will use a dmi example to explain this issue.
There are significant differences about E820 between the 1st kernel and kdump
kernel. I pasted them at bottom.
Firstly, we need to know how they are called.
__acpi_map_table()\/
early_memremap_is_setup_data()
|-> early_memremap()-> early_memremap_pgprot_adjust()-> |
memremap_is_efi_data()
dmi_early_remap()/\
memremap_should_map_decrypted()-> e820__get_entry_type()
Secondly, we also need to understand the memremap_should_map_decrypted(), which
is illustrated by the fake code.
static bool memremap_should_map_decrypted(resource_size_t phys_addr,
unsigned long size)
{
/* code ... */
switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
case E820_TYPE_RESERVED:
case E820_TYPE_ACPI:
case E820_TYPE_NVS:
case E820_TYPE_UNUSABLE:
/* For SEV, these areas are encrypted */
if (sev_active())
break;
/* Fallthrough */
case E820_TYPE_PRAM:
/* For SME, these areas are decrypted */
return true;
default:
/* these areas are encrypted by default*/
break;
}
return false;
}
For the dmi case, the dmi base address is 0x6286b000 in my test machine.
In the 1st kernel, the e820__get_entry_type() can get a valid entry and type by
the dmi address, and we can also find the dmi base address from e820.
(see the 1st kernel log)
0x6286b000 ∈ [mem 0x6286b000-0x6286efff]
So, these areas are decrypted according to the memremap_should_map_decrypted().
In kdump kernel, the dmi base address is still 0x6286b000, but we can not find
the dmi base address from e820 any more. The e820__get_entry_type() can
not get a valid entry and type by the dmi base address, it will go into the
default branch. That is to say, these areas become encrypted. In fact, these
areas are also decrypted, so we have to strengthen the logic of adjusting the
memory encryption mask.
The 1st kernel log:
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0008bfff] usable
[0.00] BIOS-e820: [mem 0x0008c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x29920fff] usable
[0.00] BIOS-e820: [mem 0x29921000-0x29921fff] reserved
[0.00] BIOS-e820: [mem 0x29922000-0x62256fff] usable
[0.00] BIOS-e820: [mem 0x62257000-0x62356fff] reserved
[0.00] BIOS-e820: [mem 0x62357000-0x6235cfff] ACPI data
[0.00] BIOS-e820: [mem 0x6235d000-0x623dbfff] usable
[0.00] BIOS-e820: [mem 0x623dc000-0x6261bfff] reserved
[0.00] BIOS-e820: [mem 0x6261c000-0x6263dfff] usable
[0.00] BIOS-e820: [mem 0x6263e000-0x6269dfff] reserved
[0.00] BIOS-e820: [mem 0x6269e000-0x627d6fff] usable
[0.00] BIOS-e820: [mem 0x627d7000-0x627e3fff] ACPI data
[0.00] BIOS-e820: [mem 0x627e4000-0x627e4fff] ACPI NVS
[0.00] BIOS-e820: [mem 0x627e5000-0x627e8fff] ACPI data
[0.00] BIOS-e820: [mem 0x627e9000-0x627eafff] usable
[0.00] BIOS-e820: [mem
Re: [PATCH 2/5 V6] x86/ioremap: strengthen the logic in early_memremap_pgprot_adjust() to adjust encryption mask
On 08/31/18 at 04:19pm, Lianbo Jiang wrote:
> For kdump kernel, when SME is enabled, the acpi table and dmi table will need
> to be remapped without the memory encryption mask. So we have to strengthen
> the logic in early_memremap_pgprot_adjust(), which makes us have an
> opportunity
> to adjust the memory encryption mask.
>
> Signed-off-by: Lianbo Jiang
> ---
> arch/x86/mm/ioremap.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index e01e6c695add..f9d9a39955f3 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -689,8 +689,15 @@ pgprot_t __init
> early_memremap_pgprot_adjust(resource_size_t phys_addr,
> encrypted_prot = true;
>
> if (sme_active()) {
> +/*
> + * In kdump kernel, the acpi table and dmi table will need
> + * to be remapped without the memory encryption mask. Here
> + * we have to strengthen the logic to adjust the memory
> + * encryption mask.
Assume the acpi/dmi tables are identical for both 1st kernel and kdump
kernel, I'm not sure what is the difference, why need special handling
for kdump. Can you add more explanations?
> + */
> if (early_memremap_is_setup_data(phys_addr, size) ||
> - memremap_is_efi_data(phys_addr, size))
> + memremap_is_efi_data(phys_addr, size) ||
> + is_kdump_kernel())
> encrypted_prot = false;
> }
>
> --
> 2.17.1
>
Thanks
Dave
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
