linux-kernel - RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks

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]

Date:	Fri, 11 Dec 2015 22:17:10 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	"Williams, Dan J" <dan.j.williams@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	linux-nvdimm <linux-nvdimm@...1.01.org>, X86 ML <x86@...nel.org>
Subject: RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover
 from machine checks

> I'm missing something, though.  The normal fixup_exception path
> doesn't touch rax at all.  The memory_failure path does.  But couldn't
> you distinguish them by just pointing the exception handlers at
> different landing pads?

Perhaps I'm just trying to take a short cut to avoid writing
some clever fixup code for the target ip that goes into the
exception table.

For __copy_user_nocache() we have four possible targets
for fixup depending on where we were in the function.

        .section .fixup,"ax"
30:     shll $6,%ecx
        addl %ecx,%edx
        jmp 60f
40:     lea (%rdx,%rcx,8),%rdx
        jmp 60f
50:     movl %ecx,%edx
60:     sfence
        jmp copy_user_handle_tail
        .previous

Note that this code also takes a shortcut
by jumping to copy_user_handle_tail() to
finish up the copy a byte at a time ... and
running back into the same page fault a 2nd
time to make sure the byte count is exactly
right.

I really, really, don't want to run back into
the poison again.  It would probably work, but
because current generation Intel cpus broadcast machine
checks to every logical cpu, it is a lot of overhead,
and potentially risky.

> Also, would it be more straightforward if the mcexception landing pad
> looked up the va -> pa mapping by itself?  Or is that somehow not
> reliable?

If we did get all the above right, then we could have
target use virt_to_phys() to convert to physical ...
I don't see that this part would be a problem.

-Tony