[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyjm2SPR=LAtve+bbdkjedD5uStg2z6=KF4+BvMuyAXAA@mail.gmail.com>
Date: Wed, 24 Feb 2016 10:35:34 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Tony Luck <tony.luck@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH v13] x86, mce: Add memcpy_trap()
On Feb 24, 2016 09:38, "Tony Luck" <tony.luck@...il.com> wrote:
>
> 2) But if we want to use this for copy_from_user() as part of the
> write(2) call stack (and I *do* want to do that)
I don't think that is even remotely an option.
If doing a rep movs can cause the chip to crash, we cannot possibly
allow user space to map these pages at all. User space could just do
"rep movs" on its own, intentionally or by mistake.
Put another way: if we cannot use the regular copy_from_user(), then
the whole concept is already dead, dead, dead.
I would suggest you instead just make regular "copy_from_user()" work
with MCE's (which may well mean "working with hardware people to make
sure it isn't a machine-killing experience").
Think of it this way: if a regular copy_from_user() doesn't work on
the memory, there's no way in hell we can allow user space to map it
anyway.
And once a regular copy_from_user() does work on it, there is no
longer any possible advantage to "memcpy_trap()".
In other words, in no situation does it make sense to make
memcpy_trap() work on user addresses. It really is that simple.
Linus
Powered by blists - more mailing lists