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

Message-ID: <3b181285-2ff3-b77a-867b-725f38ea86d3@huawei.com>
Date: Tue, 18 Feb 2025 19:51:10 +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()



在 2025/2/17 22:55, Catalin Marinas 写道:
> On Mon, Feb 17, 2025 at 04:07:49PM +0800, Tong Tiangen wrote:
>> 在 2025/2/15 1:24, Catalin Marinas 写道:
>>> On Fri, Feb 14, 2025 at 10:49:01AM +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.
>>>>
>>>> I'm sorry, I didn't catch your point, that the do_sea() and non do_sea()
>>>> paths use different exception tables?
>>>
>>> No, they would have the same exception table, only that we'd interpret
>>> it differently depending on whether it's a SEA error or not. Or rather
>>> ignore the exception table altogether for non-SEA errors.
>>
>> You mean to use the same exception type (EX_TYPE_KACCESS_ERR_ZERO) and
>> then do different processing on SEA errors and non-SEA errors, right?
> 
> Right.

Ok, now we have the same understanding.

> 
>> If so, some instructions of copy_page() did not add to the exception
>> table will be added to the exception table, and the original logic will
>> be affected.
>>
>> For example, if an instruction is not added to the exception table, the
>> instruction will panic when it triggers a non-SEA error. If this
>> instruction is added to the exception table because of SEA processing,
>> and then a non-SEA error is triggered, should we fix it?
> 
> No, we shouldn't fix it. The exception table entries have a type
> associated. For a non-SEA error, we preserve the original behaviour even
> if we find a SEA-specific entry in the exception table. You already need
> such logic even if you duplicate the code for configurations where you
> have MC enabled.


So we need another way to distinguish the different processing of the
same exception type on SEA and non-SEA path.

For example, using strcut exception_table_entry.data, the disadvantage
is that it occupies the future expansion space of data.

I still think it's better to use methods like copy_from_user.S and
copy_to_user.S calling copy_template.S, and the duplicate code in
copy_template.S.

Thanks,
Tong.

>