Add kexec cc list.
On 08/01/19 at 11:02pm, lijiang wrote:
> Hi, Tom
>
> Recently, i ran into a problem about SME and used crash tool to check the
> vmcore as follow:
>
> crash> kmem -s | grep -i invalid
> kmem: dma-kmalloc-512: slab: ffffe192c0001000 invalid freepointer:
> e5ffef4e9a040b7e
> kmem: dma-kmalloc-512: slab: ffffe192c0001000 invalid freepointer:
> e5ffef4e9a040b7e
>
> And the crash tool reported the above error, probably, the main reason is
> that kernel does not
> correctly handle the first 640k region when SME is enabled.
>
> When SME is enabled, the kernel and initramfs images are loaded into the
> decrypted memory, and
> the backup area(first 640k) is also mapped as decrypted, but the first 640k
> data is copied to
> the backup area in purgatory(). Please refer to this file:
> arch/x86/purgatory/purgatory.c
> ......
> static int copy_backup_region(void)
> {
> if (purgatory_backup_dest) {
> memcpy((void *)purgatory_backup_dest,
> (void *)purgatory_backup_src, purgatory_backup_sz);
> }
> return 0;
> }
> ......
>
> arch/x86/kernel/machine_kexec_64.c
> ......
> machine_kexec_prepare()->
> arch_update_purgatory()->
> .....
>
> Actually, the firs 640k area is encrypted in the first kernel when SME is
> enabled, here kernel
> copies the first 640k data to the backup area in purgatory(), because the
> backup area is mapped
> as decrypted, this copying operation makes that the first 640k data is
> decrypted(decoded) and
> saved to the backup area, but probably kernel can not aware of SME in
> purgatory(), which causes
> kernel mistakenly read out the first 640k.
>
> In addition, i hacked kernel code as follow:
>
> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
> index 7bcc92add72c..a51631d36a7a 100644
> --- a/fs/proc/vmcore.c
> +++ b/fs/proc/vmcore.c
> @@ -377,6 +378,16 @@ static ssize_t __read_vmcore(char *buffer, size_t
> buflen, loff_t *fpos,
> m->offset + m->size - *fpos,
> buflen);
> start = m->paddr + *fpos - m->offset;
> + if (m->paddr == 0x73f60000) {//the backup area's
> start address:0x73f60000
> + tmp = read_from_oldmem(buffer, tsz, &start,
> + userbuf, false);
> + } else
> tmp = read_from_oldmem(buffer, tsz, &start,
> userbuf, mem_encrypt_active());
> if (tmp < 0)
>
> Here, i used the crash tool to check the vmcore, i can see that the backup
> area is decrypted,
> except for the dma-kmalloc-512. So i suspect that kernel did not correctly
> read out the first
> 640k data to backup area. Do you happen to know how to deal with the first
> 640k area in purgatory()
> when SME is enabled? Any idea?
>
> BTW: I' curious the reason why the address of dma-kmalloc-512k always falls
> into the first 640k
> region, and i did not see the same issue on another machine.
>
> Machine:
> Serial Number diesel-sys9079-0001
> Model AMD Diesel (A0C)
> CPU AMD EPYC 7601 32-Core Processor
>
>
> Background:
> On x86_64, the first 640k region is special because of some historical
> reasons. And kdump kernel will
> reuse the first 640k region, so kernel will back up(copy) the first 640k
> region to a backup area in
> purgatory(), in order not to rewrite the old region(640k) in kdump kernel,
> which makes sure that kdump
> can read out the old memory from vmcore.
>
>
> Thanks.
> Lianbo
