[PATCH 0/13] Turn hrtimers into a range capable timer - Kernel

This is a discussion on [PATCH 0/13] Turn hrtimers into a range capable timer - Kernel ; On Sun 2008-09-14 09:04:08, Ulrich Drepper wrote: > On Sun, Sep 14, 2008 at 8:57 AM, Pavel Machek wrote: > >> LD_PRELOAD and other variables are ignored in security-relevant > >> contexts and environments are cleared in many situations. Sure, ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 44 of 44

Thread: [PATCH 0/13] Turn hrtimers into a range capable timer

  1. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Sun 2008-09-14 09:04:08, Ulrich Drepper wrote:
    > On Sun, Sep 14, 2008 at 8:57 AM, Pavel Machek wrote:
    > >> LD_PRELOAD and other variables are ignored in security-relevant
    > >> contexts and environments are cleared in many situations. Sure, you

    > >
    > > ...but that's okay, right? You would not want passwd to inherit huge
    > > slack specified by attacker...?

    >
    > No, it's not OK. There are enough apps which are privileged and need
    > to be handled this way. Take the X server, for instance.


    _Need_ to be handled? They are not handled that way today, and it
    still seems to work ok.

    (Plus X is no longer setuid on new distros...)

    So -- how do you prevent user from setting excessively high slack and
    interfering with ping or passwd?

    > > Well, it is not too much, but... is the cost for userspace really
    > > significant? You'd clearly want it stored in environment, not
    > > filesystem...

    >
    > You cannot really use the environment for anything meaningful.
    > Especially for this case, you couldn't change the setting for a
    > running process. What a fully-userlevel implementation would have


    Is this important enough to warrant setting for already-running
    processes? I don't think so...
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    Hi Arjan,

    Sorry for _really_ late responce.
    I recently found this patch in linux-next.

    In general, I like this patch.
    However,

    > + case PR_SET_TIMERSLACK:
    > + if (arg2 <= 0)
    > + current->timer_slack_ns =
    > + current->default_timer_slack_ns;
    > + else
    > + current->timer_slack_ns = arg2;
    > + break;
    > default:
    > error = -EINVAL;
    > break;


    I wonder to why PR_SET_TIMERSLACK decreasing doesn't need root privilege.

    example,
    nice() systemcall is
    - nice increasing (pirority decreasing) doesn't need root privilege.
    - nice decreasing (priority incriasing) need root privilege.

    So, I think time slack setting need similar one.
    Otherwise, non-privilege user can increase power consumpsion easily by PR_SET_TIMERSLACK.

    What do you think?


    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    On Tue, 30 Sep 2008 14:16:09 +0900 (JST)
    KOSAKI Motohiro wrote:

    > I wonder to why PR_SET_TIMERSLACK decreasing doesn't need root
    > privilege.
    >
    > example,
    > nice() systemcall is
    > - nice increasing (pirority decreasing) doesn't need root privilege.
    > - nice decreasing (priority incriasing) need root privilege.
    >
    > So, I think time slack setting need similar one.
    > Otherwise, non-privilege user can increase power consumpsion easily
    > by PR_SET_TIMERSLACK.
    >
    > What do you think?


    setting timerslack to 0 has no real negative effects on the system on
    the one hand, on the other hand, it'll be multimedia apps and games who
    want to do this.

    Requiring this type of app to be root doesn't sound like a good idea,
    especially since all you get by "cheating" is ... the exact behavior
    you ask for anyway. "Increased power consumption" isn't a root
    privilege, the app can consume much more power just by a "while (1);"
    loop for example.



    --
    Arjan van de Ven Intel Open Source Technology Centre
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 12/13] hrtimer: create a "timer_slack" field in the task struct

    Hi Arjan,

    Thank you for quick responce.

    > > I wonder to why PR_SET_TIMERSLACK decreasing doesn't need root
    > > privilege.
    > >
    > > example,
    > > nice() systemcall is
    > > - nice increasing (pirority decreasing) doesn't need root privilege.
    > > - nice decreasing (priority incriasing) need root privilege.
    > >
    > > So, I think time slack setting need similar one.
    > > Otherwise, non-privilege user can increase power consumpsion easily
    > > by PR_SET_TIMERSLACK.
    > >
    > > What do you think?

    >
    > setting timerslack to 0 has no real negative effects on the system on
    > the one hand, on the other hand, it'll be multimedia apps and games who
    > want to do this.
    >
    > Requiring this type of app to be root doesn't sound like a good idea,
    > especially since all you get by "cheating" is ... the exact behavior
    > you ask for anyway. "Increased power consumption" isn't a root
    > privilege, the app can consume much more power just by a "while (1);"
    > loop for example.


    Right.

    But I worry about an end user can't find a application which
    spent large power comsumption.
    Many laptop users think battery life is really really important.

    end user can find "while(1)" app easily by top command.
    but they can't find timerslack==0 app easily.

    So, I can drop my proposal. but I hope you explain your expected end user usages.



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3