linux-kernel - crash: `kmem -s` reported "kmem: dma-kmalloc-512: slab: ffffe192c0001000 invalid freepointer: e5ffef4e9a040b7e" on a dumped vmcore

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-next>] [day] [month] [year] [list]

Date:   Thu, 1 Aug 2019 23:02:49 +0800
From:   lijiang <lijiang@...hat.com>
To:     "Lendacky, Thomas" <thomas.lendacky@....com>,
        Dave Young <dyoung@...hat.com>,
        Lianbo Jiang <lijiang@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dave Anderson <anderson@...hat.com>
Subject: crash: `kmem -s` reported "kmem: dma-kmalloc-512: slab:
 ffffe192c0001000 invalid freepointer: e5ffef4e9a040b7e" on a dumped vmcore

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