From: "Jarkko Sakkinen" <jarkko.sakkinen@iki.fi>
To: "Jarkko Sakkinen" <jarkko@kernel.org>,
"Huang, Kai" <kai.huang@intel.com>, <linux-sgx@vger.kernel.org>,
<linux-mm@kvack.org>
Subject: Re: VMA merging updateds?
Date: Thu, 26 Sep 2024 13:02:13 +0300 [thread overview]
Message-ID: <D4G4OBN5HB1N.R3OYU6TQRJXY@iki.fi> (raw)
In-Reply-To: <D4FU6N3RZ30A.2TY1PVOBZ6K8X@kernel.org>
On Thu Sep 26, 2024 at 4:48 AM EEST, Jarkko Sakkinen wrote:
> > 7f8f08121000-7f8f0814a000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f0814a000-7f8f08162000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f08162000-7f8f08177000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f08177000-7f8f081a0000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f081a0000-7f8f081c1000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f081c1000-7f8f081d6000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f081d6000-7f8f081ff000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f081ff000-7f8f08228000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > 7f8f08228000-7f8ffffff000 ---p 00000000 00:00 0
> > 7f8ffffff000-7f9000000000 rw-s 00000000 00:05 84 /dev/sgx_enclave
>
> Just giving ridiculous answer to a ridiculous question.
>
> You clearly started commenting w/o reading the original thread.
It is two years since I did my own merging algorithm in user space [1].
If I recall correctly, since SGX driver does not have vm_close() by
mapping over in brk() shim you can fixup that. Obviously this needs [1]
so that you can check up from somewhere that you're doing adjacent map
with matching perms.
If nothing is done in user space, then VMA space can literally blow up
depending on the memory access pattern of the payload (in the case Enarx
it is an arbitrary program compiled to wasm, the enclave includes WASM
JIT as static payload).
I totally get if this absolute NO for core mm. Just thinking that is
SGX really the only existing location in kernel where you have:
1. pfnmap
2. bunch of regions
3. regions have varying permissions
And could there be some minimal weaker set of constraints that would
allow merges. Obviously it cannot be "any pfnmap" will go. If not,
**** it, I don't care, that's just life ;-) Stronger than pfnmap,
weaker than "struct page".
[1] https://github.com/enarx/mmledger/blob/main/src/lib.rs
BR, Jarkko
next prev parent reply other threads:[~2024-09-26 10:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 16:27 Jarkko Sakkinen
2024-09-22 16:35 ` Jarkko Sakkinen
2024-09-22 16:57 ` Jarkko Sakkinen
2024-09-23 7:48 ` Jarkko Sakkinen
2024-09-26 0:07 ` Huang, Kai
2024-09-26 0:33 ` Jarkko Sakkinen
2024-09-26 0:38 ` Jarkko Sakkinen
2024-09-26 0:53 ` Huang, Kai
2024-09-26 0:38 ` Huang, Kai
2024-09-26 1:47 ` Jarkko Sakkinen
2024-09-26 1:48 ` Jarkko Sakkinen
2024-09-26 10:02 ` Jarkko Sakkinen [this message]
2024-09-27 17:39 ` Lorenzo Stoakes
2024-09-29 22:36 ` Jarkko Sakkinen
2024-09-30 8:05 ` Lorenzo Stoakes
2024-10-09 14:03 ` Jarkko Sakkinen
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=D4G4OBN5HB1N.R3OYU6TQRJXY@iki.fi \
--to=jarkko.sakkinen@iki.fi \
--cc=jarkko@kernel.org \
--cc=kai.huang@intel.com \
--cc=linux-mm@kvack.org \
--cc=linux-sgx@vger.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