linux-kernel - Re: [PATCH v13 4/5] arm64: support copy_mc_[user]

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

Message-ID: <2c1fa758-c292-aefb-f6e2-cab41f592568@huawei.com>
Date: Tue, 4 Mar 2025 22:10:47 +0800
From: Tong Tiangen <tongtiangen@...wei.com>
To: Catalin Marinas <catalin.marinas@....com>
CC: Mark Rutland <mark.rutland@....com>, Jonathan Cameron
	<Jonathan.Cameron@...wei.com>, Mauro Carvalho Chehab
	<mchehab+huawei@...nel.org>, Will Deacon <will@...nel.org>, Andrew Morton
	<akpm@...ux-foundation.org>, James Morse <james.morse@....com>, Robin Murphy
	<robin.murphy@....com>, Andrey Konovalov <andreyknvl@...il.com>, Dmitry
 Vyukov <dvyukov@...gle.com>, Vincenzo Frascino <vincenzo.frascino@....com>,
	Michael Ellerman <mpe@...erman.id.au>, Nicholas Piggin <npiggin@...il.com>,
	Andrey Ryabinin <ryabinin.a.a@...il.com>, Alexander Potapenko
	<glider@...gle.com>, Christophe Leroy <christophe.leroy@...roup.eu>, Aneesh
 Kumar K.V <aneesh.kumar@...nel.org>, "Naveen N. Rao"
	<naveen.n.rao@...ux.ibm.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo
 Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave Hansen
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>, "H. Peter Anvin"
	<hpa@...or.com>, Madhavan Srinivasan <maddy@...ux.ibm.com>,
	<linux-arm-kernel@...ts.infradead.org>, <linux-mm@...ck.org>,
	<linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>,
	<kasan-dev@...glegroups.com>, <wangkefeng.wang@...wei.com>, Guohanjun
	<guohanjun@...wei.com>
Subject: Re: [PATCH v13 4/5] arm64: support copy_mc_[user]_highpage()

Hi,Catalin:

Kindly ping ...

Thanks.:)

在 2025/2/19 3:42, Catalin Marinas 写道:
> On Tue, Feb 18, 2025 at 07:51:10PM +0800, Tong Tiangen wrote:
>>>>>> 在 2025/2/13 1:11, Catalin Marinas 写道:
>>>>>>> On Mon, Dec 09, 2024 at 10:42:56AM +0800, Tong Tiangen wrote:
>>>>>>>> Currently, many scenarios that can tolerate memory errors when copying page
>>>>>>>> have been supported in the kernel[1~5], all of which are implemented by
>>>>>>>> copy_mc_[user]_highpage(). arm64 should also support this mechanism.
>>>>>>>>
>>>>>>>> Due to mte, arm64 needs to have its own copy_mc_[user]_highpage()
>>>>>>>> architecture implementation, macros __HAVE_ARCH_COPY_MC_HIGHPAGE and
>>>>>>>> __HAVE_ARCH_COPY_MC_USER_HIGHPAGE have been added to control it.
>>>>>>>>
>>>>>>>> Add new helper copy_mc_page() which provide a page copy implementation with
>>>>>>>> hardware memory error safe. The code logic of copy_mc_page() is the same as
>>>>>>>> copy_page(), the main difference is that the ldp insn of copy_mc_page()
>>>>>>>> contains the fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR, therefore, the
>>>>>>>> main logic is extracted to copy_page_template.S. In addition, the fixup of
>>>>>>>> MOPS insn is not considered at present.
>>>>>>>
>>>>>>> Could we not add the exception table entry permanently but ignore the
>>>>>>> exception table entry if it's not on the do_sea() path? That would save
>>>>>>> some code duplication.
> [...]
>> So we need another way to distinguish the different processing of the
>> same exception type on SEA and non-SEA path.
> 
> Distinguishing whether the fault is SEA or non-SEA is already done by
> the exception handling you are adding. What we don't have though is
> information about whether the caller invoked copy_highpage() or
> copy_mc_highpage(). That's where the code duplication comes in handy.
> 
> It's a shame we need to duplicate identical functions just to have
> different addresses to look up in the exception table. We are also short
> of caller saved registers to track this information (e.g. an extra
> argument to those functions that the exception handler interprets).
> 
> I need to think a bit more, we could in theory get the arm64 memcpy_mc()
> to return an error code depending on what type of fault it got (e.g.
> -EHWPOISON for SEA, -EFAULT for non-SEA). copy_mc_highpage() would
> interpret this one and panic if -EFAULT. But we lose some fault details
> we normally get on a faulty access like some of the registers.
> 
> Well, maybe the simples is still to keep the function duplication. I'll
> have another look at the series tomorrow.
>