All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"hughd@google.com" <hughd@google.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"Huang, Ying" <ying.huang@intel.com>,
	"riel@surriel.com" <riel@surriel.com>,
	"npiggin@gmail.com" <npiggin@gmail.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"kirill@shutemov.name" <kirill@shutemov.name>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"osalvador@suse.de" <osalvador@suse.de>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"aneesh.kumar@linux.ibm.com" <aneesh.kumar@linux.ibm.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>
Subject: Re: [PATCH 6/7] mm/x86: Add missing pud helpers
Date: Fri, 21 Jun 2024 16:27:44 -0400	[thread overview]
Message-ID: <ZnXiQAJsKPBAKa6b@x1n> (raw)
In-Reply-To: <db95c7abea9cd252a791d15359a4d940d91524e3.camel@intel.com>

On Fri, Jun 21, 2024 at 07:36:30PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
> > 
> > But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
> > to make it Dirty=1,Write=0?  What prevents that from being
> > misinterpreted by the hardware as being a valid 1G shadow stack mapping?
> 
> Hmm, it looks like we could use an arch_check_zapped_pud() that does a warning
> like arch_check_zapped_pte/pmd() too. Not that we had no use for one before
> this.

I can definitely look into that, but this check only happens when zapping,
and IIUC it means there can still be outliers floating around.  I wonder
whether it should rely on page_table_check_pxx_set() from that regard.

Thanks,

-- 
Peter Xu


WARNING: multiple messages have this Message-ID (diff)
From: Peter Xu <peterx@redhat.com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Hansen, Dave" <dave.hansen@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"hughd@google.com" <hughd@google.com>,
	"willy@infradead.org" <willy@infradead.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"kirill@shutemov.name" <kirill@shutemov.name>,
	"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
	"Jiang, Dave" <dave.jiang@intel.com>,
	"aneesh.kumar@linux.ibm.com" <aneesh.kumar@linux.ibm.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"riel@surriel.com" <riel@surriel.com>,
	"npiggin@gmail.com" <npiggin@gmail.com>,
	"osalvador@suse.de" <osalvador@suse.de>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"bp@alien8.de" <bp@alien8.de>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
	"Huang, Ying" <ying.huang@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH 6/7] mm/x86: Add missing pud helpers
Date: Fri, 21 Jun 2024 16:27:44 -0400	[thread overview]
Message-ID: <ZnXiQAJsKPBAKa6b@x1n> (raw)
In-Reply-To: <db95c7abea9cd252a791d15359a4d940d91524e3.camel@intel.com>

On Fri, Jun 21, 2024 at 07:36:30PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2024-06-21 at 07:51 -0700, Dave Hansen wrote:
> > 
> > But, still, what if you take a Dirty=1,Write=1 pud and pud_modify() it
> > to make it Dirty=1,Write=0?  What prevents that from being
> > misinterpreted by the hardware as being a valid 1G shadow stack mapping?
> 
> Hmm, it looks like we could use an arch_check_zapped_pud() that does a warning
> like arch_check_zapped_pte/pmd() too. Not that we had no use for one before
> this.

I can definitely look into that, but this check only happens when zapping,
and IIUC it means there can still be outliers floating around.  I wonder
whether it should rely on page_table_check_pxx_set() from that regard.

Thanks,

-- 
Peter Xu



  reply	other threads:[~2024-06-21 20:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 14:24 [PATCH 0/7] mm/mprotect: Fix dax puds Peter Xu
2024-06-21 14:24 ` Peter Xu
2024-06-21 14:24 ` [PATCH 1/7] mm/dax: Dump start address in fault handler Peter Xu
2024-06-21 14:24   ` Peter Xu
2024-06-21 14:24 ` [PATCH 2/7] mm/mprotect: Remove NUMA_HUGE_PTE_UPDATES Peter Xu
2024-06-21 14:24   ` Peter Xu
2024-06-21 14:25 ` [PATCH 3/7] mm/mprotect: Push mmu notifier to PUDs Peter Xu
2024-06-21 14:25   ` Peter Xu
2024-06-21 14:25 ` [PATCH 4/7] mm/powerpc: Add missing pud helpers Peter Xu
2024-06-21 14:25   ` Peter Xu
2024-06-21 15:01   ` Peter Xu
2024-06-21 15:01     ` Peter Xu
2024-06-21 14:25 ` [PATCH 5/7] mm/x86: Make pud_leaf() only cares about PSE bit Peter Xu
2024-06-21 14:25   ` Peter Xu
2024-06-21 14:32   ` Dave Hansen
2024-06-21 14:32     ` Dave Hansen
2024-06-21 14:25 ` [PATCH 6/7] mm/x86: Add missing pud helpers Peter Xu
2024-06-21 14:25   ` Peter Xu
2024-06-21 14:51   ` Dave Hansen
2024-06-21 14:51     ` Dave Hansen
2024-06-21 15:45     ` Peter Xu
2024-06-21 15:45       ` Peter Xu
2024-06-21 16:11       ` Dave Hansen
2024-06-21 16:11         ` Dave Hansen
2024-06-23 15:42         ` Peter Xu
2024-06-23 15:42           ` Peter Xu
2024-06-21 19:36     ` Edgecombe, Rick P
2024-06-21 19:36       ` Edgecombe, Rick P
2024-06-21 20:27       ` Peter Xu [this message]
2024-06-21 20:27         ` Peter Xu
2024-06-21 22:06         ` Edgecombe, Rick P
2024-06-21 22:06           ` Edgecombe, Rick P
2024-06-21 14:25 ` [PATCH 7/7] mm/mprotect: fix dax pud handlings Peter Xu
2024-06-21 14:25   ` Peter Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZnXiQAJsKPBAKa6b@x1n \
    --to=peterx@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave.jiang@intel.com \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@redhat.com \
    --cc=npiggin@gmail.com \
    --cc=osalvador@suse.de \
    --cc=rick.p.edgecombe@intel.com \
    --cc=riel@surriel.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.