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: <20250307224645.GKZ8t3VX5a5FhqNyZG@fat_crate.local>
Date: Fri, 7 Mar 2025 23:46:45 +0100
From: Borislav Petkov <bp@...en8.de>
To: "Luck, Tony" <tony.luck@...el.com>
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

On Fri, Mar 07, 2025 at 10:05:12PM +0000, Luck, Tony wrote:
> 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...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette