| Message ID | 20210618132826.54670-2-steven.price@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | MTE support for KVM guest | expand |
On Fri, Jun 18, 2021 at 02:28:20PM +0100, Steven Price wrote: > mte_sync_tags() used test_and_set_bit() to set the PG_mte_tagged flag > before restoring/zeroing the MTE tags. However if another thread were to > race and attempt to sync the tags on the same page before the first > thread had completed restoring/zeroing then it would see the flag is > already set and continue without waiting. This would potentially expose > the previous contents of the tags to user space, and cause any updates > that user space makes before the restoring/zeroing has completed to > potentially be lost. > > Since this code is run from atomic contexts we can't just lock the page > during the process. Instead implement a new (global) spinlock to protect > the mte_sync_page_tags() function. > > Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE") > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> > Signed-off-by: Steven Price <steven.price@arm.com> Although I reviewed this patch, I think we should drop it from this series and restart the discussion with the Chromium guys on what/if they need PROT_MTE with MAP_SHARED. It currently breaks if you have two PROT_MTE mappings but if they are ok with only one of the mappings being PROT_MTE, I'm happy to just document it. Not sure whether subsequent patches depend on it though.
On 2021-06-18 15:40, Catalin Marinas wrote: > On Fri, Jun 18, 2021 at 02:28:20PM +0100, Steven Price wrote: >> mte_sync_tags() used test_and_set_bit() to set the PG_mte_tagged flag >> before restoring/zeroing the MTE tags. However if another thread were >> to >> race and attempt to sync the tags on the same page before the first >> thread had completed restoring/zeroing then it would see the flag is >> already set and continue without waiting. This would potentially >> expose >> the previous contents of the tags to user space, and cause any updates >> that user space makes before the restoring/zeroing has completed to >> potentially be lost. >> >> Since this code is run from atomic contexts we can't just lock the >> page >> during the process. Instead implement a new (global) spinlock to >> protect >> the mte_sync_page_tags() function. >> >> Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped >> in user-space with PROT_MTE") >> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> >> Signed-off-by: Steven Price <steven.price@arm.com> > > Although I reviewed this patch, I think we should drop it from this > series and restart the discussion with the Chromium guys on what/if > they > need PROT_MTE with MAP_SHARED. It currently breaks if you have two > PROT_MTE mappings but if they are ok with only one of the mappings > being > PROT_MTE, I'm happy to just document it. > > Not sure whether subsequent patches depend on it though. I'd certainly like it to be independent of the KVM series, specially as this series is pretty explicit that this MTE lock is not required for KVM. This will require some rework of patch #2, I believe. And while we're at it, a rebase on 5.13-rc4 wouldn't hurt, as both patches #3 and #5 conflict with it... Thanks, M.
On 18/06/2021 16:42, Marc Zyngier wrote: > On 2021-06-18 15:40, Catalin Marinas wrote: >> On Fri, Jun 18, 2021 at 02:28:20PM +0100, Steven Price wrote: >>> mte_sync_tags() used test_and_set_bit() to set the PG_mte_tagged flag >>> before restoring/zeroing the MTE tags. However if another thread were to >>> race and attempt to sync the tags on the same page before the first >>> thread had completed restoring/zeroing then it would see the flag is >>> already set and continue without waiting. This would potentially expose >>> the previous contents of the tags to user space, and cause any updates >>> that user space makes before the restoring/zeroing has completed to >>> potentially be lost. >>> >>> Since this code is run from atomic contexts we can't just lock the page >>> during the process. Instead implement a new (global) spinlock to protect >>> the mte_sync_page_tags() function. >>> >>> Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is >>> mapped in user-space with PROT_MTE") >>> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> >>> Signed-off-by: Steven Price <steven.price@arm.com> >> >> Although I reviewed this patch, I think we should drop it from this >> series and restart the discussion with the Chromium guys on what/if they >> need PROT_MTE with MAP_SHARED. It currently breaks if you have two >> PROT_MTE mappings but if they are ok with only one of the mappings being >> PROT_MTE, I'm happy to just document it. >> >> Not sure whether subsequent patches depend on it though. > > I'd certainly like it to be independent of the KVM series, specially > as this series is pretty explicit that this MTE lock is not required > for KVM. Sure, since KVM no longer uses the lock we don't have the dependency - so I'll drop the first patch. > This will require some rework of patch #2, I believe. And while we're > at it, a rebase on 5.13-rc4 wouldn't hurt, as both patches #3 and #5 > conflict with it... Yeah there will be minor conflicts in patch #2 - but nothing major. I'll rebase as requested at the same time. Thanks, Steve
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c index 125a10e413e9..a3583a7fd400 100644 --- a/arch/arm64/kernel/mte.c +++ b/arch/arm64/kernel/mte.c @@ -25,6 +25,7 @@ u64 gcr_kernel_excl __ro_after_init; static bool report_fault_once = true; +static DEFINE_SPINLOCK(tag_sync_lock); #ifdef CONFIG_KASAN_HW_TAGS /* Whether the MTE asynchronous mode is enabled. */ @@ -34,13 +35,22 @@ EXPORT_SYMBOL_GPL(mte_async_mode); static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap) { + unsigned long flags; pte_t old_pte = READ_ONCE(*ptep); + spin_lock_irqsave(&tag_sync_lock, flags); + + /* Recheck with the lock held */ + if (test_bit(PG_mte_tagged, &page->flags)) + goto out; + if (check_swap && is_swap_pte(old_pte)) { swp_entry_t entry = pte_to_swp_entry(old_pte); - if (!non_swap_entry(entry) && mte_restore_tags(entry, page)) - return; + if (!non_swap_entry(entry) && mte_restore_tags(entry, page)) { + set_bit(PG_mte_tagged, &page->flags); + goto out; + } } page_kasan_tag_reset(page); @@ -53,6 +63,10 @@ static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap) */ smp_wmb(); mte_clear_page_tags(page_address(page)); + set_bit(PG_mte_tagged, &page->flags); + +out: + spin_unlock_irqrestore(&tag_sync_lock, flags); } void mte_sync_tags(pte_t *ptep, pte_t pte) @@ -63,7 +77,7 @@ void mte_sync_tags(pte_t *ptep, pte_t pte) /* if PG_mte_tagged is set, tags have already been initialised */ for (i = 0; i < nr_pages; i++, page++) { - if (!test_and_set_bit(PG_mte_tagged, &page->flags)) + if (!test_bit(PG_mte_tagged, &page->flags)) mte_sync_page_tags(page, ptep, check_swap); } }
mte_sync_tags() used test_and_set_bit() to set the PG_mte_tagged flag before restoring/zeroing the MTE tags. However if another thread were to race and attempt to sync the tags on the same page before the first thread had completed restoring/zeroing then it would see the flag is already set and continue without waiting. This would potentially expose the previous contents of the tags to user space, and cause any updates that user space makes before the restoring/zeroing has completed to potentially be lost. Since this code is run from atomic contexts we can't just lock the page during the process. Instead implement a new (global) spinlock to protect the mte_sync_page_tags() function. Fixes: 34bfeea4a9e9 ("arm64: mte: Clear the tags when a page is mapped in user-space with PROT_MTE") Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> --- arch/arm64/kernel/mte.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-)