| 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
| ||
|
Message-ID: <CAGsJ_4wXawhY5OsjjZUkgaBwXeFeBbcZa5NcsWETgXty=iogJg@mail.gmail.com>
Date: Thu, 30 Nov 2023 13:34:13 +1300
From: Barry Song <21cnbao@...il.com>
To: Ryan Roberts <ryan.roberts@....com>
Cc: akpm@...ux-foundation.org, andreyknvl@...il.com,
anshuman.khandual@....com, ardb@...nel.org,
catalin.marinas@....com, david@...hat.com, dvyukov@...gle.com,
glider@...gle.com, james.morse@....com, jhubbard@...dia.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, mark.rutland@....com, maz@...nel.org,
oliver.upton@...ux.dev, ryabinin.a.a@...il.com,
suzuki.poulose@....com, vincenzo.frascino@....com,
wangkefeng.wang@...wei.com, will@...nel.org, willy@...radead.org,
yuzenghui@...wei.com, yuzhao@...gle.com, ziy@...dia.com
Subject: Re: [PATCH v2 01/14] mm: Batch-copy PTE ranges during fork()
On Thu, Nov 30, 2023 at 3:07 AM Ryan Roberts <ryan.roberts@....com> wrote:
>
> On 29/11/2023 13:09, Barry Song wrote:
> > On Thu, Nov 30, 2023 at 1:29 AM Ryan Roberts <ryan.roberts@....com> wrote:
> >>
> >> On 28/11/2023 19:00, Barry Song wrote:
> >>> On Wed, Nov 29, 2023 at 12:00 AM Ryan Roberts <ryan.roberts@....com> wrote:
> >>>>
> >>>> On 28/11/2023 00:11, Barry Song wrote:
> >>>>> On Mon, Nov 27, 2023 at 10:24 PM Ryan Roberts <ryan.roberts@....com> wrote:
> >>>>>>
> >>>>>> On 27/11/2023 05:54, Barry Song wrote:
> >>>>>>>> +copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
> >>>>>>>> + pte_t *dst_pte, pte_t *src_pte,
> >>>>>>>> + unsigned long addr, unsigned long end,
> >>>>>>>> + int *rss, struct folio **prealloc)
> >>>>>>>> {
> >>>>>>>> struct mm_struct *src_mm = src_vma->vm_mm;
> >>>>>>>> unsigned long vm_flags = src_vma->vm_flags;
> >>>>>>>> pte_t pte = ptep_get(src_pte);
> >>>>>>>> struct page *page;
> >>>>>>>> struct folio *folio;
> >>>>>>>> + int nr = 1;
> >>>>>>>> + bool anon;
> >>>>>>>> + bool any_dirty = pte_dirty(pte);
> >>>>>>>> + int i;
> >>>>>>>>
> >>>>>>>> page = vm_normal_page(src_vma, addr, pte);
> >>>>>>>> - if (page)
> >>>>>>>> + if (page) {
> >>>>>>>> folio = page_folio(page);
> >>>>>>>> - if (page && folio_test_anon(folio)) {
> >>>>>>>> - /*
> >>>>>>>> - * If this page may have been pinned by the parent process,
> >>>>>>>> - * copy the page immediately for the child so that we'll always
> >>>>>>>> - * guarantee the pinned page won't be randomly replaced in the
> >>>>>>>> - * future.
> >>>>>>>> - */
> >>>>>>>> - folio_get(folio);
> >>>>>>>> - if (unlikely(page_try_dup_anon_rmap(page, false, src_vma))) {
> >>>>>>>> - /* Page may be pinned, we have to copy. */
> >>>>>>>> - folio_put(folio);
> >>>>>>>> - return copy_present_page(dst_vma, src_vma, dst_pte, src_pte,
> >>>>>>>> - addr, rss, prealloc, page);
> >>>>>>>> + anon = folio_test_anon(folio);
> >>>>>>>> + nr = folio_nr_pages_cont_mapped(folio, page, src_pte, addr,
> >>>>>>>> + end, pte, &any_dirty);
> >>>>>>>
> >>>>>>> in case we have a large folio with 16 CONTPTE basepages, and userspace
> >>>>>>> do madvise(addr + 4KB * 5, DONTNEED);
> >>>>>>
> >>>>>> nit: if you are offsetting by 5 pages from addr, then below I think you mean
> >>>>>> page0~page4 and page6~15?
> >>>>>>
> >>>>>>>
> >>>>>>> thus, the 4th basepage of PTE becomes PTE_NONE and folio_nr_pages_cont_mapped()
> >>>>>>> will return 15. in this case, we should copy page0~page3 and page5~page15.
> >>>>>>
> >>>>>> No I don't think folio_nr_pages_cont_mapped() will return 15; that's certainly
> >>>>>> not how its intended to work. The function is scanning forwards from the current
> >>>>>> pte until it finds the first pte that does not fit in the batch - either because
> >>>>>> it maps a PFN that is not contiguous, or because the permissions are different
> >>>>>> (although this is being relaxed a bit; see conversation with DavidH against this
> >>>>>> same patch).
> >>>>>>
> >>>>>> So the first time through this loop, folio_nr_pages_cont_mapped() will return 5,
> >>>>>> (page0~page4) then the next time through the loop we will go through the
> >>>>>> !present path and process the single swap marker. Then the 3rd time through the
> >>>>>> loop folio_nr_pages_cont_mapped() will return 10.
> >>>>>
> >>>>> one case we have met by running hundreds of real phones is as below,
> >>>>>
> >>>>>
> >>>>> static int
> >>>>> copy_pte_range(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma,
> >>>>> pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
> >>>>> unsigned long end)
> >>>>> {
> >>>>> ...
> >>>>> dst_pte = pte_alloc_map_lock(dst_mm, dst_pmd, addr, &dst_ptl);
> >>>>> if (!dst_pte) {
> >>>>> ret = -ENOMEM;
> >>>>> goto out;
> >>>>> }
> >>>>> src_pte = pte_offset_map_nolock(src_mm, src_pmd, addr, &src_ptl);
> >>>>> if (!src_pte) {
> >>>>> pte_unmap_unlock(dst_pte, dst_ptl);
> >>>>> /* ret == 0 */
> >>>>> goto out;
> >>>>> }
> >>>>> spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
> >>>>> orig_src_pte = src_pte;
> >>>>> orig_dst_pte = dst_pte;
> >>>>> arch_enter_lazy_mmu_mode();
> >>>>>
> >>>>> do {
> >>>>> /*
> >>>>> * We are holding two locks at this point - either of them
> >>>>> * could generate latencies in another task on another CPU.
> >>>>> */
> >>>>> if (progress >= 32) {
> >>>>> progress = 0;
> >>>>> if (need_resched() ||
> >>>>> spin_needbreak(src_ptl) || spin_needbreak(dst_ptl))
> >>>>> break;
> >>>>> }
> >>>>> ptent = ptep_get(src_pte);
> >>>>> if (pte_none(ptent)) {
> >>>>> progress++;
> >>>>> continue;
> >>>>> }
> >>>>>
> >>>>> the above iteration can break when progress > =32. for example, at the
> >>>>> beginning,
> >>>>> if all PTEs are none, we break when progress >=32, and we break when we
> >>>>> are in the 8th pte of 16PTEs which might become CONTPTE after we release
> >>>>> PTL.
> >>>>>
> >>>>> since we are releasing PTLs, next time when we get PTL, those pte_none() might
> >>>>> become pte_cont(), then are you going to copy CONTPTE from 8th pte,
> >>>>> thus, immediately
> >>>>> break the consistent CONPTEs rule of hardware?
> >>>>>
> >>>>> pte0 - pte_none
> >>>>> pte1 - pte_none
> >>>>> ...
> >>>>> pte7 - pte_none
> >>>>>
> >>>>> pte8 - pte_cont
> >>>>> ...
> >>>>> pte15 - pte_cont
> >>>>>
> >>>>> so we did some modification to avoid a break in the middle of PTEs
> >>>>> which can potentially
> >>>>> become CONTPE.
> >>>>> do {
> >>>>> /*
> >>>>> * We are holding two locks at this point - either of them
> >>>>> * could generate latencies in another task on another CPU.
> >>>>> */
> >>>>> if (progress >= 32) {
> >>>>> progress = 0;
> >>>>> #ifdef CONFIG_CONT_PTE_HUGEPAGE
> >>>>> /*
> >>>>> * XXX: don't release ptl at an unligned address as
> >>>>> cont_pte might form while
> >>>>> * ptl is released, this causes double-map
> >>>>> */
> >>>>> if (!vma_is_chp_anonymous(src_vma) ||
> >>>>> (vma_is_chp_anonymous(src_vma) && IS_ALIGNED(addr,
> >>>>> HPAGE_CONT_PTE_SIZE)))
> >>>>> #endif
> >>>>> if (need_resched() ||
> >>>>> spin_needbreak(src_ptl) || spin_needbreak(dst_ptl))
> >>>>> break;
> >>>>> }
> >>>>>
> >>>>> We could only reproduce the above issue by running thousands of phones.
> >>>>>
> >>>>> Does your code survive from this problem?
> >>>>
> >>>> Yes I'm confident my code is safe against this; as I said before, the CONT_PTE
> >>>> bit is not blindly "copied" from parent to child pte. As far as the core-mm is
> >>>> concerned, there is no CONT_PTE bit; they are just regular PTEs. So the code
> >>>> will see some pte_none() entries followed by some pte_present() entries. And
> >>>> when calling set_ptes() on the child, the arch code will evaluate the current
> >>>> state of the pgtable along with the new set_ptes() request and determine where
> >>>> it should insert the CONT_PTE bit.
> >>>
> >>> yep, i have read very carefully and think your code is safe here. The
> >>> only problem
> >>> is that the code can randomly unfold parent processes' CONPTE while setting
> >>> wrprotect in the middle of a large folio while it actually should keep CONT
> >>> bit as all PTEs can be still consistent if we set protect from the 1st PTE.
> >>>
> >>> while A forks B, progress >= 32 might interrupt in the middle of a
> >>> new CONTPTE folio which is forming, as we have to set wrprotect to parent A,
> >>> this parent immediately loses CONT bit. this is sad. but i can't find a
> >>> good way to resolve it unless CONT is exposed to mm-core. any idea on
> >>> this?
> >>
> >> No this is not the case; copy_present_ptes() will copy as many ptes as are
> >> physcially contiguous and belong to the same folio (which usually means "the
> >> whole folio" - the only time it doesn't is when we hit the end of the vma). We
> >> will then return to the main loop and move forwards by the number of ptes that
> >> were serviced, including:
> >
> > I probably have failed to describe my question. i'd like to give a
> > concrete example
> >
> > 1. process A forks B
> > 2. At the beginning, address~address +64KB has pte_none PTEs
> > 3. we scan the 5th pte of address + 5 * 4KB, progress becomes 32, we
> > break and release PTLs
> > 4. another page fault in process A gets PTL and set
> > address~address+64KB to pte_cont
> > 5. we get the PTL again and arrive 5th pte
> > 6. we set wrprotects on 5,6,7....15 ptes, in this case, we have to
> > unfold parent A
> > and child B also gets unfolded PTEs unless our loop can go back the 0th pte.
> >
> > technically, A should be able to keep CONTPTE, but because of the implementation
> > of the code, it can't. That is the sadness. but it is obviously not your fault.
> >
> > no worries. This is not happening quite often. but i just want to make a note
> > here, maybe someday we can get back to address it.
>
> Ahh, I understand the situation now, sorry for being slow!
>
> I expect this to be a very rare situation anyway since (4) suggests process A
> has another thread, and forking is not encouraged for multithreaded programs. In
> fact the fork man page says:
>
> After a fork() in a multithreaded program, the child can safely call only
> async-signal-safe functions (see signal-safety(7)) until such time as it calls
> execve(2).
>
> So in this case, we are about to completely repaint the child's address space
> with execve() anyway.
>
> So its just the racing parent that loses the CONT_PTE bit. I expect this to be
> extremely rare. I'm not sure there is much we can do to solve it though, because
> unlike with your solution, we have to cater for multiple sizes so there is no
> obvious boarder until we get to PMD size and I'm guessing that's going to be a
> problem for latency spikes.
right. i don't think this can be a big problem. the background is that
we have some
way to constantly detect and report unexpected unfold/events, so we run hundreds
of phones in lab, and collect data to find out if we have any
potential problems. we
record unexpected unfold and reasons in a proc file, we monitor those data to
look for potential bugs we might have. this ">=32" break and unfold was found in
this way, thus we simply addressed it by disallowing the break at an unaligned
address.
This is never an issue which can stop your patchset. but I was still
glad to share
our observations with you and would like to hear if you had any idea :-)
>
>
> >
> >>
> >> progress += 8 * ret;
> >>
> >> That might go above 32, so we will flash the lock. But we haven't done that in
> >> the middle of a large folio. So the contpte-ness should be preserved.
> >>
> >>>
> >>> Our code[1] resolves this by only breaking at the aligned address
> >>>
> >>> if (progress >= 32) {
> >>> progress = 0;
> >>> #ifdef CONFIG_CONT_PTE_HUGEPAGE
> >>> /*
> >>> * XXX: don't release ptl at an unligned address as cont_pte
> >>> might form while
> >>> * ptl is released, this causes double-map
> >>> */
> >>> if (!vma_is_chp_anonymous(src_vma) ||
> >>> (vma_is_chp_anonymous(src_vma) && IS_ALIGNED(addr,
> >>> HPAGE_CONT_PTE_SIZE)))
> >>> #endif
> >>> if (need_resched() ||
> >>> spin_needbreak(src_ptl) || spin_needbreak(dst_ptl))
> >>> break;
> >>> }
> >>>
> >>> [1] https://github.com/OnePlusOSS/android_kernel_oneplus_sm8550/blob/oneplus/sm8550_u_14.0.0_oneplus11/mm/memory.c#L1180
Thanks
Barry
Powered by blists - more mailing lists