linux-kernel - Re: [PATCH v28 09/32] x86/mm: Introduce _PAGE

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: <9a2b91ea-6a07-b7c8-24ac-3a15f62fbb7c@intel.com>
Date:   Wed, 18 Aug 2021 09:38:30 -0700
From:   "Yu, Yu-cheng" <yu-cheng.yu@...el.com>
To:     Borislav Petkov <bp@...en8.de>, Andy Lutomirski <luto@...nel.org>
CC:     "luto@...capital.net" <luto@...capital.net>,
        the arch/x86 maintainers <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-mm@...ck.org>,
        <linux-arch@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Balbir Singh <bsingharora@...il.com>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Eugene Syromiatnikov <esyr@...hat.com>,
        Florian Weimer <fweimer@...hat.com>,
        "H.J. Lu" <hjl.tools@...il.com>, "Jann Horn" <jannh@...gle.com>,
        Jonathan Corbet <corbet@....net>,
        Kees Cook <keescook@...omium.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Nadav Amit <nadav.amit@...il.com>,
        Oleg Nesterov <oleg@...hat.com>, Pavel Machek <pavel@....cz>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "Dave Martin" <Dave.Martin@....com>,
        Weijiang Yang <weijiang.yang@...el.com>,
        Pengfei Xu <pengfei.xu@...el.com>,
        Haitao Huang <haitao.huang@...el.com>,
        Rick P Edgecombe <rick.p.edgecombe@...el.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH v28 09/32] x86/mm: Introduce _PAGE_COW

On 8/17/2021 2:01 PM, Borislav Petkov wrote:
> On Tue, Aug 17, 2021 at 01:51:52PM -0700, Andy Lutomirski wrote:
>> WRSS can be used from user mode depending on the configuration.
> 
> My point being, if you're going to do shadow stack management
> operations, you should check whether the target you're writing to is a
> shadow stack page. Clearly userspace can't do that but userspace will
> get notified of that pretty timely.
> 
>> Double-you shmouble-you. You can't write it with MOV, but you can
>> write it from user code and from kernel code. As far as the mm is
>> concerned, I think it should be considered writable.
> 
> Because?
> 
>> Although... anyone who tries to copy_to_user() it is going to be a bit
>> surprised. Hmm.
> 
> Ok, so you see the confusion.
> 

copy_to_user() can run into normal read-only areas too.  The caller can 
handle that just fine.

> In any case, I don't think you can simply look at a shadow stack page as
> simple writable page. There are cases where it is going to be fun.
> 
> So why are we even saying that a shadow stack page is writable? Why
> can't we simply say that a shadow stack page is, well, something
> special?
> 

We can visualize the type of a mm area by looking at vma->vm_flags, e.g. 
maybe_mkwrite(), and PTE macros as lower-level operatives.  These two 
have some relations but not one-to-one.  Note that a PTE in a writable 
area is not always pte_write().

I have considered and implemented a shadow stack PTE either pte_write() 
or not.  Making shadow stack as pte_write() results in less arch_* 
macros and less confusion in copy-on-write code.  That is one more thing 
to consider.

Thanks,
Yu-cheng