linux-kernel - Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per

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: <CALmYWFuXTd5qYLa=rEkoFbzSk07PjdKExgKsUkgMkT2E1Pjrtg@mail.gmail.com>
Date: Mon, 5 Aug 2024 18:22:51 -0700
From: Jeff Xu <jeffxu@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Nicholas Piggin <npiggin@...il.com>, Michael Ellerman <mpe@...erman.id.au>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, Pedro Falcato <pedro.falcato@...il.com>, 
	kernel test robot <oliver.sang@...el.com>, Jeff Xu <jeffxu@...omium.org>, oe-lkp@...ts.linux.dev, 
	lkp@...el.com, linux-kernel@...r.kernel.org, 
	Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <keescook@...omium.org>, 
	"Liam R. Howlett" <Liam.Howlett@...cle.com>, Dave Hansen <dave.hansen@...el.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Guenter Roeck <groeck@...omium.org>, 
	Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, 
	Jorge Lucangeli Obes <jorgelo@...omium.org>, Matthew Wilcox <willy@...radead.org>, 
	Muhammad Usama Anjum <usama.anjum@...labora.com>, Stephen Röttger <sroettger@...gle.com>, 
	Suren Baghdasaryan <surenb@...gle.com>, Amer Al Shanawany <amer.shanawany@...il.com>, 
	Javier Carrasco <javier.carrasco.cruz@...il.com>, Shuah Khan <shuah@...nel.org>, 
	linux-api@...r.kernel.org, linux-mm@...ck.org, ying.huang@...el.com, 
	feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [mseal] 8be7258aad: stress-ng.pagemove.page_remaps_per_sec
 -4.4% regression

On Mon, Aug 5, 2024 at 5:13 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Mon, 5 Aug 2024 at 16:25, Nicholas Piggin <npiggin@...il.com> wrote:
> >
> > Can userspace on other archs not unmap their vdsos?
>
> I think they can, and nobody cares. The "context.vdso" value stays at
> some stale value, and anybody who tries to use it will just fail.
>
I want to seal the vdso :-), so I also care (not having it changeable
from userspace)

For the restore scenario, if vdso is sealed,  I guess CRIU won't be
able to relocate the vdso from userspace, I 'm interested in hearing
vdso dev's input on this , e.g. is that possible to make CRIU
compatible with memory sealing.

> So what makes powerpc special is not "you can unmap the vdso", but
> "powerpc cares".
>
> I just don't quite know _why_ powerpc cares.
>
> Judging by the comments and a quick 'grep', the reason may be
>
>     arch/powerpc/perf/callchain_32.c
>
> which seems to have some vdso knowledge.
>
> But x86 does something kind of like that at signal frame generation
> time, and doesn't care.
>
> I really think it's an issue of "if you screw with the vdso, you get
> to keep both broken pieces".
>
>            Linus