Re: [RFC PATCH v9 16/27] mm: Update can_follow_write_pte() for Shadow Stack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> +inline bool pte_exclusive(pte_t pte, struct vm_area_struct *vma)
> +{
> +	if (vma->vm_flags & VM_SHSTK)
> +		return pte_dirty_hw(pte);
> +	else
> +		return pte_dirty(pte);
> +}

I'm not really getting the naming.  What is exclusive?

> diff --git a/mm/gup.c b/mm/gup.c
> index 7646bf993b25..d1dbfbde8443 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -164,10 +164,12 @@ static int follow_pfn_pte(struct vm_area_struct *vma, unsigned long address,
>   * FOLL_FORCE can write to even unwritable pte's, but only
>   * after we've gone through a COW cycle and they are dirty.
>   */
> -static inline bool can_follow_write_pte(pte_t pte, unsigned int flags)
> +static inline bool can_follow_write(pte_t pte, unsigned int flags,
> +				    struct vm_area_struct *vma)

Having two identically named functions in two files in the same
subsystem seems like a recipe for confusion when I grep or cscope for
things.  It hardly seems worth the 4 characters of space savings IMNHO.

>  {
>  	return pte_write(pte) ||
> -		((flags & FOLL_FORCE) && (flags & FOLL_COW) && pte_dirty(pte));
> +		((flags & FOLL_FORCE) && (flags & FOLL_COW) &&
> +		 pte_exclusive(pte, vma));
>  }

FWIW, this is the hunk that fixed DirtyCOW.

The least this deserves is acknowledgement of that in the changelog and
a missive about how you're sure you didn't just introduce
ShadowDirtyCOW.  Don't bother.  I already registered the domain. ;)



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux