linux-kernel - RE: [PATCH v4 1/3] x86/mce: Use is_copy_from_user() to determine copy-from-user context

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]

Message-ID: <SJ1PR11MB6083223A3175F7A84EC4DDDFFCD52@SJ1PR11MB6083.namprd11.prod.outlook.com>
Date: Fri, 7 Mar 2025 23:11:26 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: Shuai Xue <xueshuai@...ux.alibaba.com>, "peterz@...radead.org"
	<peterz@...radead.org>, "catalin.marinas@....com" <catalin.marinas@....com>,
	"yazen.ghannam@....com" <yazen.ghannam@....com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linmiaohe@...wei.com" <linmiaohe@...wei.com>,
	"nao.horiguchi@...il.com" <nao.horiguchi@...il.com>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "jpoimboe@...nel.org"
	<jpoimboe@...nel.org>, "linux-edac@...r.kernel.org"
	<linux-edac@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"baolin.wang@...ux.alibaba.com" <baolin.wang@...ux.alibaba.com>,
	"tianruidong@...ux.alibaba.com" <tianruidong@...ux.alibaba.com>
Subject: RE: [PATCH v4 1/3] x86/mce: Use is_copy_from_user() to determine
 copy-from-user context

> > is_copy_from_user() decodes the instruction that took the trap. It looks for
> > MOV, MOVZ and MOVS instructions to find the source address, and then
> > checks whether that's user (< TASK_SIZE_MAX) or kernel.
>
> You mean there's absolutely nothing else like, say, some epbf or some other
> hackery we tend to do in the kernel (or we will do in the future) which won't
> create the exact same two conditions:
>
> - one of the three insns
> - user mem read
>
> and it would cause a recovery action.
>
> Perhaps it still might be the proper thing to do even then but it does sound
> fishy and unclean to me.
>
> Nothing beats the explicit markup we had until recently...

Every "user mem read" needs to have an extable[] recovery entry
attached to the IP of the instruction  (to handle the much more common
#PF for page-not-present). All those places already have to deal with
the possibility that the #PF can't be recovered. The #MC handling is
really just a small extension.

As for "explicit markup" I don't think it would be better to decorate
every get_user() and copy_from_user() with some "this one can
recover from #MC" 

Note also that "what we had recently" was fragile, broke, and resulted
in this regression.

-Tony