From: Andrei Vagin <avagin@gmail.com>
To: Jeff Xu <jeffxu@chromium.org>
Cc: akpm@linux-foundation.org, keescook@chromium.org,
jannh@google.com, torvalds@linux-foundation.org,
adhemerval.zanella@linaro.org, oleg@redhat.com,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com,
ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de,
mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com,
deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net,
hch@lst.de, peterx@redhat.com, hca@linux.ibm.com,
f.fainelli@gmail.com, gerg@kernel.org,
dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org,
Liam.Howlett@oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com,
peterz@infradead.org, ardb@google.com, enh@google.com,
rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au,
Dmitry Safonov <0x7f454c46@gmail.com>,
Mike Rapoport <mike.rapoport@gmail.com>,
Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>,
Andrei Vagin <avagin@google.com>
Subject: Re: [PATCH v4 1/1] exec: seal system mappings
Date: Thu, 12 Dec 2024 22:33:21 -0800 [thread overview]
Message-ID: <CANaxB-z57KoCNawGEkmpoiHV_iCaYr8YiOc2zQiTHM4fso0ABQ@mail.gmail.com> (raw)
In-Reply-To: <CABi2SkXgZfTvyPX_rcb8KTKyeHxpZrL9_2Wr+vJ1q3K3_1rwoQ@mail.gmail.com>
On Wed, Dec 11, 2024 at 2:47 PM Jeff Xu <jeffxu@chromium.org> wrote:
>
> Hi Andrei
>
> Thanks for your email.
> I was hoping to get some feedback from CRIU devs, and happy to see you
> reaching out..
>
...
> I have been thinking of other alternatives, but those would require
> more understanding on CRIU use cases.
> One of my questions is: Would CRIU target an individual process? or
> entire systems?
It targets individual processes that have been forked from the main
CRIU process.
>
> If it is an individual process, we could use prctl to opt-in/opt-out
> certain processes. There could be two alternatives.
> 1> Opt-in solution: process must set prctl.seal_criu_mapping, this
> needs to be set before execve() because sealing is applied at execve()
> call.
> 2> opt-out solution: The system will by default seal all of the system
> mappings, but individual processes can opt-out by setting
> prctl.not_seal_criu_mappings. This also needs to be set before
> execve() call.
I like the idea and I think the opt-out solution should work for CRIU.
CRIU will be able to call this prctl and re-execute itself.
Let me give you a bit of context on how CRIU works. When CRIU restores
processes, it recreates a process tree by forking itself. Afterwards, it
restores all mappings in each process but doesn't put them to proper
addresses. After that, each process unmaps CRIU mappings from its address
space and remaps its restored mappings to the proper addresses. So CRIU should
be able to move system mappings and seal them if they have been sealed before
dump.
BTW, It isn't just about CRIU. gVisor and maybe some other sandbox solutions
will be affected by this change too. gVisor uses stub-processes to represent
guest address spaces. In a stub process, it unmaps all system mappings.
>
> For both cases, we will want to identify what type of mapping CRIU
> cares about, i.e. maybe CRIU doesn't care about uprobe and vsyscall ?
> and only care about vdso/vvar/sigpage ?
As for now, it handles only vdso/vvar/sigpage mappings. It doesn't care
about vsyscall because it is always mapped to the fixed address.
gVisor should be able to unmap all system mappings from a process
address space.
Thanks,
Andrei
next prev parent reply other threads:[~2024-12-13 6:33 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-25 20:20 [PATCH v4 0/1] Seal " jeffxu
2024-11-25 20:20 ` [PATCH v4 1/1] exec: seal " jeffxu
2024-11-25 20:40 ` Matthew Wilcox
2024-12-02 17:22 ` Jeff Xu
2024-12-02 17:57 ` Lorenzo Stoakes
2024-12-02 20:05 ` Jeff Xu
2024-12-02 19:57 ` Jeff Xu
2024-12-02 18:29 ` Lorenzo Stoakes
2024-12-02 20:38 ` Jeff Xu
2024-12-03 7:35 ` Lorenzo Stoakes
2024-12-03 18:19 ` Jeff Xu
2024-12-03 20:16 ` Lorenzo Stoakes
2024-12-04 14:04 ` Benjamin Berg
2024-12-04 17:43 ` Jeff Xu
2024-12-04 18:24 ` Benjamin Berg
2024-12-10 4:12 ` Andrei Vagin
2024-12-11 22:46 ` Jeff Xu
2024-12-13 6:33 ` Andrei Vagin [this message]
2024-12-16 18:35 ` Jeff Xu
2024-12-16 18:56 ` Liam R. Howlett
2024-12-16 20:20 ` Jeff Xu
2024-12-17 22:18 ` Kees Cook
2025-01-02 19:15 ` Andrei Vagin
2025-01-03 20:48 ` Liam R. Howlett
2025-01-07 1:17 ` Kees Cook
2025-02-04 18:17 ` Johannes Berg
2025-01-03 21:38 ` Lorenzo Stoakes
2025-01-07 1:12 ` Kees Cook
2025-01-13 21:26 ` Jeff Xu
2025-01-14 4:19 ` Matthew Wilcox
2025-01-15 19:02 ` Jeff Xu
2025-01-15 19:46 ` Lorenzo Stoakes
2025-01-15 20:20 ` Jeff Xu
2025-01-16 15:48 ` Lorenzo Stoakes
2025-01-16 17:01 ` Benjamin Berg
2025-01-16 17:16 ` Lorenzo Stoakes
2025-01-16 17:18 ` Pedro Falcato
2025-01-17 18:20 ` Jeff Xu
2025-01-17 19:35 ` enh
2025-01-17 20:15 ` Jeff Xu
2025-01-17 22:08 ` Liam R. Howlett
2025-01-21 15:38 ` enh
2025-01-22 17:23 ` Liam R. Howlett
2025-01-22 22:29 ` enh
2025-01-23 8:40 ` Vlastimil Babka
2025-01-23 21:50 ` enh
2025-01-23 22:38 ` Matthew Wilcox
2025-02-06 14:19 ` enh
2025-02-06 13:20 ` Thomas Weißschuh
2025-02-06 14:38 ` enh
2025-02-06 15:28 ` Thomas Weißschuh
2025-02-06 15:51 ` enh
2025-02-06 16:37 ` Thomas Weißschuh
2025-01-17 18:08 ` Jeff Xu
2025-01-15 23:52 ` Kees Cook
2025-01-16 5:26 ` Christoph Hellwig
2025-01-16 19:40 ` Kees Cook
2025-01-17 10:14 ` Heiko Carstens
2025-01-16 15:34 ` Lorenzo Stoakes
2025-01-16 19:44 ` Kees Cook
2024-11-26 16:39 ` [PATCH v4 0/1] Seal " Lorenzo Stoakes
2024-12-02 17:28 ` Jeff 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=CANaxB-z57KoCNawGEkmpoiHV_iCaYr8YiOc2zQiTHM4fso0ABQ@mail.gmail.com \
--to=avagin@gmail.com \
--cc=0x7f454c46@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@oracle.com \
--cc=adhemerval.zanella@linaro.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksandr.mikhalitsyn@canonical.com \
--cc=anna-maria@linutronix.de \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=avagin@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=enh@google.com \
--cc=f.fainelli@gmail.com \
--cc=gerg@kernel.org \
--cc=groeck@chromium.org \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=jorgelo@chromium.org \
--cc=keescook@chromium.org \
--cc=linus.walleij@linaro.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mike.rapoport@gmail.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=ojeda@kernel.org \
--cc=oleg@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=sroettger@google.com \
--cc=torvalds@linux-foundation.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