[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] proxy memory object
From: |
Marcus Brinkmann |
Subject: |
Re: [PATCH] proxy memory object |
Date: |
Mon, 13 Jun 2005 12:53:43 +0200 |
User-agent: |
Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI) |
At Sun, 12 Jun 2005 19:07:52 -0700 (PDT),
Roland McGrath wrote:
>
> > There is something funky about the arrays. I originally wanted to use
> > "^array[]", but that was a loser.
>
> What was the problem?
I didn't see the right data.
> I haven't played with ^array[], but I know about
> out-of-line parameters generally in the kernel. The server stub gets
> passed a vm_map_copy_t (cast to io_buf_ptr_t, i.e. char *) when the
> parameter is out of line.You have to use vm_map_copyout on kernel_map to
> look at the contents.
Ah, ok. That must have been it, I just tried to use the pointer
directly. Do you think it is worth to go through this trouble here?
> > The patch is tested and seems to work just fine for a single memory
> > object, where offset and start are 0 and len is ~0.
>
> store_map (or store type map hooks) could use this to fabricate a memory
> object for a partitoin or remap store. That would test some useful cases
> with offsets and limits. I really think at least some elementary tests of
> the nontrivial arguments should be tested before it goes in.
>
> Hmm, it looks like you haven't implemented that stuff at all, not just not
> tested it.
Right.
> I am a little dubious about putting in the RPC with all those
> args when they aren't implemented. I suppose there won't be many users to
> change if the signature winds up changing.
Yeah, all-right, but I would be happy if you could make up your mind
on this. Last time this came up I posted a complete, working patch
with just the args I needed for the simple case. At that time, Thomas
asked me to modify the prototype to allow for a range restriction, and
you asked me to also take into account multiple objects.
There are three options here, and I don't really care which one we go for:
1. Apply my original patch from Nov 20 2002 (!!!).
But why didn't we do it 2-and-a-half years ago when I already made
clear that I won't implement the generic case fully?
2. Apply my new patch, with the generic interface.
3. Somebody commits _now_ to implement the generic case within a reasonably
short time frame. I won't do it.
This is, for me, all about fixing a glaring security hole, which has
existed ever since. Well, since some time it is also about allowing
for tmpfs and shared memory, but that is a side-issue.
Thanks,
Marcus