Re: [PATCH v2 22/39] mm: Don't allow write GUPs to shadow stack memory

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

 



On Sat, 2022-10-01 at 01:00 +0200, Jann Horn wrote:
> On Fri, Sep 30, 2022 at 9:16 PM Dave Hansen <dave.hansen@xxxxxxxxx>
> wrote:
> > On 9/29/22 15:29, Rick Edgecombe wrote:
> > > @@ -1633,6 +1633,9 @@ static inline bool
> > > __pte_access_permitted(unsigned long pteval, bool write)
> > >   {
> > >        unsigned long need_pte_bits = _PAGE_PRESENT|_PAGE_USER;
> > > 
> > > +     if (write && (pteval & (_PAGE_RW | _PAGE_DIRTY)) ==
> > > _PAGE_DIRTY)
> > > +             return 0;
> > 
> > Do we not have a helper for this?  Seems a bit messy to open-code
> > these
> > shadow-stack permissions.  Definitely at least needs a comment.
> 
> FWIW, if you look at more context around this diff, the function
> looks
> like this:
> 
>  static inline bool __pte_access_permitted(unsigned long pteval, bool
> write)
>  {
>         unsigned long need_pte_bits = _PAGE_PRESENT|_PAGE_USER;
> 
> +       if (write && (pteval & (_PAGE_RW | _PAGE_DIRTY)) ==
> _PAGE_DIRTY)
> +               return 0;
> +
>         if (write)
>                 need_pte_bits |= _PAGE_RW;
> 
>         if ((pteval & need_pte_bits) != need_pte_bits)
>                 return 0;
> 
>         return __pkru_allows_pkey(pte_flags_pkey(pteval), write);
>  }
> 
> So I think this change is actually a no-op - the only thing it does
> is
> to return 0 if write==1, !_PAGE_RW, and _PAGE_DIRTY. But the check
> below will always return 0 if !_PAGE_RW, unless I'm misreading it?
> And
> this is the only patch in the series that touches this function, so
> it's not like this becomes necessary with a later patch in the series
> either.
> 
> Should this check go in anyway for clarity reasons, or should this
> instead be a comment explaining that __pte_access_permitted() behaves
> just like the hardware access check, which means shadow pages are
> treated as readonly?

Thanks Jann, I was just realizing the same thing. Yes, I think it
doesn't do anything. I can add a comment of why there is no check, but
otherwise the check seems like unnecessary work.




[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux