Re: [resend][PATCH] Added PR_SET_PROCTITLE_AREA option for prctl()

Hi

Sorry for the delaying.

On Sat, Oct 10, 2009 at 2:32 AM, KOSAKI Motohiro
[off-list ref] wrote:

quoted

quoted

It does seem like a maximum spin count should be put in there - and
maybe a timeout as well (since with FUSE etc it's possible to engineer
page faults that take arbitrarily long).
Also, it occurs to me that:

makes sense.
I like maximum spin rather than timeout.

I'm worried about the scenario where process A sets its cmdline buffer
to point to a page which will take a _VERY_ long time to pagein (maybe
forever), and then process B goes to try to read its cmdline. What
happens now?

Honestly, I don't worry about so much. if attacker want DoS attack, fork bomb is
efficient than this way. then, attacker never use this.

Process A can arrange for this to happen by using a FUSE filesystem
that sits on a read forever. And since the first thing the admin's
likely to do to track down the problem is 'ps awux', this is liable to
be a rather nasty DoS...

Probably, I haven't understand this paragraph. Why is this FUSE related issue?

Of course, this is no worse than it is now - it's already possible to
replace the page in question. But we should think about ways this
could be fixed for good...

Plus, please look my mesurement data as another post. seqlock implementation is very fast
although contention occured.

quoted

quoted

quoted

+     do {
+             seq = read_seqbegin(&mm->arg_lock);
+
+             len = mm->arg_end - mm->arg_start;
+             if (len > PAGE_SIZE)
+                     len = PAGE_SIZE;

If arg_end or arg_start are modified after this, is it truly safe to
assume that len will remain <= PAGE_SIZE without a memory barrier
before the conditional?

1) access_process_vm() doesn't return error value.
2) read_seqretry(&mm->arg_lock, seq)) check seq, not mm->arg_start or len.

then, if arg_{start,end} is modified, access_process_vm() may return 0
and strnlen
makes bad calculation, but read_seqretry() can detect its modify
rightly. I think.

No, I'm worried about what if the compiler decides to rewrite like so:
if (mm->arg_end - mm->arg_start > PAGE_SIZE)
  len = PAGE_SIZE;
else /* here we reload arg_end/arg_start! */
  len = mm->arg_end - mm->arg_start;

Now we might write into buffer more than PAGE_SIZE bytes, which is
probably a buffer overrun into kernel space...

Rgiht. I'll fix this issue at next spin.
Thank you.