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: <Z7NN5Pa-c5PtIbcF@arm.com>
Date: Mon, 17 Feb 2025 14:55:32 +0000
From: Catalin Marinas <catalin.marinas@....com>
To: Tong Tiangen <tongtiangen@...wei.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()

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.

> 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.

-- 
Catalin