lkml.org 
[lkml]   [2010]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 12/12][PATCH] SCHED_DEADLINE: modified sched_*_ex API
From
Date
On Wed, 2010-01-13 at 11:27 +0100, Raistlin wrote:
> On Mon, 2009-12-28 at 16:09 +0100, Peter Zijlstra wrote:
> > On Fri, 2009-10-16 at 17:48 +0200, Raistlin wrote:
> > > @@ -6807,9 +6811,10 @@ out_unlock:
> > > /**
> > > * sys_sched_getparam - get the DEADLINE task parameters of a thread
> > > * @pid: the pid in question.
> > > + * @len: size of data pointed by param_ex.
> > > * @param_ex: structure containing the new parameters (deadline, runtime, etc.).
> > > */
> > > -SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid,
> > > +SYSCALL_DEFINE3(sched_getparam_ex, pid_t, pid, unsigned, len,
> > > struct sched_param_ex __user *, param_ex)
> > > {
> > > struct sched_param_ex lp;
> > > @@ -6818,6 +6823,8 @@ SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid,
> > >
> > > if (!param_ex || pid < 0)
> > > return -EINVAL;
> > > + if (len < sizeof(struct sched_param_ex))
> > > + return -EINVAL;
> > >
> > > read_lock(&tasklist_lock);
> > > p = find_process_by_pid(pid);
> >
> > This allows len > sizeof().
> >
> Yes...
>
> > > @@ -6837,7 +6844,7 @@ SYSCALL_DEFINE2(sched_getparam_ex, pid_t, pid,
> > > /*
> > > * This one might sleep, we cannot do it with a spinlock held ....
> > > */
> > > - retval = copy_to_user(param_ex, &lp, sizeof(*param_ex)) ? -EFAULT : 0;
> > > + retval = copy_to_user(param_ex, &lp, len) ? -EFAULT : 0;
> > >
> > > return retval;
> >
> > Which would copy more than lp, resulting in a stack leak, right?
> >
> .... And yes again! :-)
>
> This has been done bearing in mind that the _kernel_side_ sched_param_ex
> --once stabilized-- will never lower its size. I.e., it should always
> grow and, if/when it does, it should retain the position of existing
> fields, for the sake of backward compatibility.
>
> In that case, I think, the only possible case we have to face is the one
> where the "old" userspace program/library uses a version of
> sched_param_ex which is smaller than the one in the kernel, and what we
> want is the kernel to fill only the fields existing in the userspace
> code.
>
> Does all this make sense?

> If yes, I guess I just have to flip the inequality in the if() turning
> it into "if (len > sizeof())" (, then apologize for the glaring
> bug! :-P) and then I'm done, am I?

Right, I think so..



\
 
 \ /
  Last update: 2010-01-13 17:27    [W:1.090 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site