linux-kernel - Re: [PATCH] hugetlbfs: add MTE support

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: <Zr3ZFmRqtkbrOJq7@arm.com>
Date: Thu, 15 Aug 2024 11:31:50 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Yang Shi <yang@...amperecomputing.com>
Cc: muchun.song@...ux.dev, will@...nel.org, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hugetlbfs: add MTE support

Sorry for the delay (holidays etc.)

On Tue, Jul 09, 2024 at 10:42:58AM -0700, Yang Shi wrote:
> On 7/4/24 6:44 AM, Catalin Marinas wrote:
> > It might be better to convert those page flag checks to only happen on
> > the head page. My stashed changes from over a year ago (before we had
> > more folio conversions) below. However, as I mentioned, I got stuck on
> > folio_copy() which also does a cond_resched() between copy_highpage().
> 
> We can have the page flags set for head only for hugetlb page. For
> copy_highpage(), we should be able to do something like the below:
> 
> if  page_is_head && page_is_hugetlb && page_has_mte_tagged
>     set page_mte_tagged flags
>     copy tags for all sub pages
> else // <-- tail page or non-hugetlb page
>     current copy_highpage implementation

Ah, so you want in the first copy_highpage() for the head page to
populate the tags for the tail pages. I guess this would work.

> The hugetlb folio can't go away under us since migration path should pin it
> so the status of folio is stable. The preemption caused by cond_resched()
> should be fine too due to the pin and the page table entry keeps being
> migration entry until migration is done, so every one should just see
> migration entry and wait for migration is done.

Yeah, I don't see those pages going away, otherwise folio_copy() would
corrupt data.

> The other concerned user of copy_highpage() is uprobe, but it also pins the
> page then doing copy and it is called with holding write mmap_lock.
> 
> IIUC, it should work if I don't miss something. This also should have no
> impact on HVO. The overhead for other users of copy_highpage() should be
> also acceptable.

I also think so. We also have the copy_user_highpage() on arm64 that
calls copy_highpage() but I think that's also safe.

-- 
Catalin