linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>,
	"Liam.Howlett@oracle.com" <Liam.Howlett@oracle.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"bp@alien8.de" <bp@alien8.de>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"debug@rivosinc.com" <debug@rivosinc.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"luto@kernel.org" <luto@kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"peterz@infradead.org" <peterz@infradead.org>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"x86@kernel.org" <x86@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>,
	"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
	"Naveen N . Rao" <naveen.n.rao@linux.ibm.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v3 07/12] powerpc: Use initializer for struct vm_unmapped_area_info
Date: Wed, 13 Mar 2024 06:44:15 +0000	[thread overview]
Message-ID: <dad7735d-dc57-4c89-a2b2-29d971f3cf69@csgroup.eu> (raw)
In-Reply-To: <20240312222843.2505560-8-rick.p.edgecombe@intel.com>



Le 12/03/2024 à 23:28, Rick Edgecombe a écrit :
> Future changes will need to add a new member to struct
> vm_unmapped_area_info. This would cause trouble for any call site that
> doesn't initialize the struct. Currently every caller sets each member
> manually, so if new members are added they will be uninitialized and the
> core code parsing the struct will see garbage in the new member.
> 
> It could be possible to initialize the new member manually to 0 at each
> call site. This and a couple other options were discussed, and a working
> consensus (see links) was that in general the best way to accomplish this
> would be via static initialization with designated member initiators.
> Having some struct vm_unmapped_area_info instances not zero initialized
> will put those sites at risk of feeding garbage into vm_unmapped_area() if
> the convention is to zero initialize the struct and any new member addition
> misses a call site that initializes each member manually.
> 
> It could be possible to leave the code mostly untouched, and just change
> the line:
> struct vm_unmapped_area_info info
> to:
> struct vm_unmapped_area_info info = {};
> 
> However, that would leave cleanup for the members that are manually set
> to zero, as it would no longer be required.
> 
> So to be reduce the chance of bugs via uninitialized members, instead
> simply continue the process to initialize the struct this way tree wide.
> This will zero any unspecified members. Move the member initializers to the
> struct declaration when they are known at that time. Leave the members out
> that were manually initialized to zero, as this would be redundant for
> designated initializers.

I understand from this text that, as agreed, this patch removes the 
pointless/redundant zero-init of individual members. But it is not what 
is done, see below ?

> 
> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
> Acked-by: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Link: https://lore.kernel.org/lkml/202402280912.33AEE7A9CF@keescook/#t
> Link: https://lore.kernel.org/lkml/j7bfvig3gew3qruouxrh7z7ehjjafrgkbcmg6tcghhfh3rhmzi@wzlcoecgy5rs/
> ---
> v3:
>   - Fixed spelling errors in log
>   - Be consistent about field vs member in log
> 
> Hi,
> 
> This patch was split and refactored out of a tree-wide change [0] to just
> zero-init each struct vm_unmapped_area_info. The overall goal of the
> series is to help shadow stack guard gaps. Currently, there is only one
> arch with shadow stacks, but two more are in progress. It is compile tested
> only.
> 
> There was further discussion that this method of initializing the structs
> while nice in some ways has a greater risk of introducing bugs in some of
> the more complicated callers. Since this version was reviewed my arch
> maintainers already, leave it as was already acknowledged.
> 
> Thanks,
> 
> Rick
> 
> [0] https://lore.kernel.org/lkml/20240226190951.3240433-6-rick.p.edgecombe@intel.com/
> ---
>   arch/powerpc/mm/book3s64/slice.c | 23 ++++++++++++-----------
>   1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/powerpc/mm/book3s64/slice.c b/arch/powerpc/mm/book3s64/slice.c
> index c0b58afb9a47..6c7ac8c73a6c 100644
> --- a/arch/powerpc/mm/book3s64/slice.c
> +++ b/arch/powerpc/mm/book3s64/slice.c
> @@ -282,12 +282,12 @@ static unsigned long slice_find_area_bottomup(struct mm_struct *mm,
>   {
>   	int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT);
>   	unsigned long found, next_end;
> -	struct vm_unmapped_area_info info;
> -
> -	info.flags = 0;
> -	info.length = len;
> -	info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
> -	info.align_offset = 0;
> +	struct vm_unmapped_area_info info = {
> +		.flags = 0,

Please remove zero-init as agreed and explained in the commit message

> +		.length = len,
> +		.align_mask = PAGE_MASK & ((1ul << pshift) - 1),
> +		.align_offset = 0

Same here.

> +	};
>   	/*
>   	 * Check till the allow max value for this mmap request
>   	 */
> @@ -326,13 +326,14 @@ static unsigned long slice_find_area_topdown(struct mm_struct *mm,
>   {
>   	int pshift = max_t(int, mmu_psize_defs[psize].shift, PAGE_SHIFT);
>   	unsigned long found, prev;
> -	struct vm_unmapped_area_info info;
> +	struct vm_unmapped_area_info info = {
> +		.flags = VM_UNMAPPED_AREA_TOPDOWN,
> +		.length = len,
> +		.align_mask = PAGE_MASK & ((1ul << pshift) - 1),
> +		.align_offset = 0

Same here.

> +	};
>   	unsigned long min_addr = max(PAGE_SIZE, mmap_min_addr);
>   
> -	info.flags = VM_UNMAPPED_AREA_TOPDOWN;
> -	info.length = len;
> -	info.align_mask = PAGE_MASK & ((1ul << pshift) - 1);
> -	info.align_offset = 0;
>   	/*
>   	 * If we are trying to allocate above DEFAULT_MAP_WINDOW
>   	 * Add the different to the mmap_base.

Christophe

  reply	other threads:[~2024-03-13  6:44 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-12 22:28 [PATCH v3 00/12] Cover a guard gap corner case Rick Edgecombe
2024-03-12 22:28 ` [PATCH v3 01/12] mm: Switch mm->get_unmapped_area() to a flag Rick Edgecombe
2024-03-13  7:19   ` Christophe Leroy
2024-03-13 14:48     ` Edgecombe, Rick P
2024-03-13 17:20       ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 02/12] mm: Introduce arch_get_unmapped_area_vmflags() Rick Edgecombe
2024-03-13  7:22   ` Christophe Leroy
2024-03-13 14:51     ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 03/12] mm: Use get_unmapped_area_vmflags() Rick Edgecombe
2024-03-13  9:05   ` Christophe Leroy
2024-03-13 14:55     ` Edgecombe, Rick P
2024-03-13 16:49       ` Christophe Leroy
2024-03-13 15:55     ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 04/12] thp: Add thp_get_unmapped_area_vmflags() Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 05/12] csky: Use initializer for struct vm_unmapped_area_info Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 06/12] parisc: " Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 07/12] powerpc: " Rick Edgecombe
2024-03-13  6:44   ` Christophe Leroy [this message]
2024-03-13 14:57     ` Edgecombe, Rick P
2024-03-13 21:58       ` Michael Ellerman
2024-03-12 22:28 ` [PATCH v3 08/12] treewide: " Rick Edgecombe
2024-03-13  3:18   ` Kees Cook
2024-03-13 15:40     ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 09/12] mm: Take placement mappings gap into account Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-13 14:58     ` Edgecombe, Rick P
2024-03-13 16:51       ` Christophe Leroy
2024-03-12 22:28 ` [PATCH v3 10/12] x86/mm: Implement HAVE_ARCH_UNMAPPED_AREA_VMFLAGS Rick Edgecombe
2024-03-13  9:04   ` Christophe Leroy
2024-03-13 16:00     ` Edgecombe, Rick P
2024-03-18  1:00       ` Edgecombe, Rick P
2024-03-12 22:28 ` [PATCH v3 11/12] x86/mm: Care about shadow stack guard gap during placement Rick Edgecombe
2024-03-12 22:28 ` [PATCH v3 12/12] selftests/x86: Add placement guard gap test for shstk Rick Edgecombe

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=dad7735d-dc57-4c89-a2b2-29d971f3cf69@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@kernel.org \
    --cc=bp@alien8.de \
    --cc=broonie@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=debug@rivosinc.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox