[PATCH] getrusage sucks

[PATCH] getrusage sucks

[Claudio Scordino]

Does exist any _real_ reason why getrusage can't be invoked by a task to know 
statistics of another task ?

The changes would be very trivial, as shown by the following patch.

              Claudio


diff --git a/kernel/sys.c b/kernel/sys.c
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1746,9 +1746,13 @@ int getrusage(struct task_struct *p, int

 asmlinkage long sys_getrusage(int who, struct rusage __user *ru)
 {
-  if (who != RUSAGE_SELF && who != RUSAGE_CHILDREN)
-     return -EINVAL;
-  return getrusage(current, who, ru);
+  if (who != RUSAGE_SELF && who != RUSAGE_CHILDREN) {
+      struct task_struct* tsk = find_task_by_pid(who);
+      if (tsk == NULL)
+        return -EINVAL;
+     return getrusage(tsk, RUSAGE_SELF, ru);
+   } else
+     return getrusage(current, who, ru);
 }

 asmlinkage long sys_umask(int mask)

Re: [PATCH] getrusage sucks

[David Wagner]

Claudio Scordino  wrote:
>Does exist any _real_ reason why getrusage can't be invoked by a task to know 
>statistics of another task ?

Probably only super-user should be permitted to read the usage information
about other processes.  Allowing anyone to read anyone else's rusage would
open up a bunch of side channels that sound pretty dangerous.  For instance,
user #1 might be able to mount a timing attack against crypto code being
executed by user #2, and that doesn't sound good.

Re: [PATCH] getrusage sucks

[Lee Revell]

On Fri, 2005-11-11 at 05:06 +0000, David Wagner wrote:
> Claudio Scordino  wrote:
> >Does exist any _real_ reason why getrusage can't be invoked by a task to know 
> >statistics of another task ?
> 
> Probably only super-user should be permitted to read the usage information
> about other processes.  Allowing anyone to read anyone else's rusage would
> open up a bunch of side channels that sound pretty dangerous.  For instance,
> user #1 might be able to mount a timing attack against crypto code being
> executed by user #2, and that doesn't sound good.

Why restrict it to root?  Why not just prevent users from reading other
users rusage.  How could it be a security hole for joeuser's process be
able to read the rusage of joeuser's other processes?

Lee

Re: [PATCH] getrusage sucks

[David Wagner]

Lee Revell  wrote:
>On Fri, 2005-11-11 at 05:06 +0000, David Wagner wrote:
>> Probably only super-user should be permitted to read the usage information
>> about other processes.
>
>Why restrict it to root?  Why not just prevent users from reading other
>users rusage.  How could it be a security hole for joeuser's process be
>able to read the rusage of joeuser's other processes?

Sorry; you're absolutely right.  I agree.  I overlooked that case.

How to quickly detect the mode change of a hard disk?

[Hui Cheng]

Hi,

I am currently doing a kernel module involves detecting/changing
disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue
commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a
drive in standby mode will automatically awake whenever a disk operation
is requested and I need to know the mode change as soon as possible. (So I
donot want to periodically use the WIN_CHECKPOWERMODE to detect it). I was
wondering if the standby disk is waken by the kernel or by the disk
firmware? If it is not in the kernel, is there any good way to detect it?
Thanks,

Hui

Re: How to quickly detect the mode change of a hard disk?

[Pavel Machek]

> I am currently doing a kernel module involves detecting/changing
> disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue
> commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a
> drive in standby mode will automatically awake whenever a disk operation
> is requested and I need to know the mode change as soon as possible. (So I

AFAIK there's no nice way to get that info, but it is useful, so patch would
be welcome.
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: How to quickly detect the mode change of a hard disk?

[Alejandro Bonilla]

On Sun, 13 Nov 2005 15:10:56 +0000, Pavel Machek wrote
> > I am currently doing a kernel module involves detecting/changing
> > disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue
> > commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a
> > drive in standby mode will automatically awake whenever a disk operation
> > is requested and I need to know the mode change as soon as possible. (So I
> 
> AFAIK there's no nice way to get that info, but it is useful, so 
> patch would be welcome.

I would check the hdparm man page again. Still, it sounds interesting.

Additionally, it could be cool if someone could finish up or make the option
for the HD freeze to use it with the HDAPS driver. ;-)

.Alejandro

Re: How to quickly detect the mode change of a hard disk?

[Hui Cheng]

On Wed, 16 Nov 2005, Alejandro Bonilla wrote:

> On Sun, 13 Nov 2005 15:10:56 +0000, Pavel Machek wrote
> > > I am currently doing a kernel module involves detecting/changing
> > > disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue
> > > commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a
> > > drive in standby mode will automatically awake whenever a disk operation
> > > is requested and I need to know the mode change as soon as possible. (So I
> >
> > AFAIK there's no nice way to get that info, but it is useful, so
> > patch would be welcome.
>
> I would check the hdparm man page again. Still, it sounds interesting.
>
> Additionally, it could be cool if someone could finish up or make the option
> for the HD freeze to use it with the HDAPS driver. ;-)
>
> .Alejandro
>

Thanks for reply :) What I did to handle this problem is a little stupid
: Suppose the disk is now in a standby mode. In case that there is a
request sent to the disk drive, a kernel thread is awake to detect/update
the current disk power mode. The disk power mode is stored in the
ide_drive_t structure and be protected by lock. It seems to work fine in
my simple tests. But again, there should be better solutions.

Hui

Re: How to quickly detect the mode change of a hard disk?

[Pavel Machek]

Hi!

> > > > I am currently doing a kernel module involves detecting/changing
> > > > disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue
> > > > commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a
> > > > drive in standby mode will automatically awake whenever a disk operation
> > > > is requested and I need to know the mode change as soon as possible. (So I
> > >
> > > AFAIK there's no nice way to get that info, but it is useful, so
> > > patch would be welcome.
> >
> > I would check the hdparm man page again. Still, it sounds interesting.
> >
> > Additionally, it could be cool if someone could finish up or make the option
> > for the HD freeze to use it with the HDAPS driver. ;-)
> >
> > .Alejandro
> >
> 
> Thanks for reply :) What I did to handle this problem is a little stupid
> : Suppose the disk is now in a standby mode. In case that there is a
> request sent to the disk drive, a kernel thread is awake to detect/update
> the current disk power mode. The disk power mode is stored in the
> ide_drive_t structure and be protected by lock. It seems to work fine in
> my simple tests. But again, there should be better solutions.

Can we get the patch?
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: How to quickly detect the mode change of a hard disk?

[Hui Cheng]

On Sat, 19 Nov 2005, Pavel Machek wrote:
Hi,

> Hi!
>
> > > > > I am currently doing a kernel module involves detecting/changing
> > > > > disk mode among STANDBY and ACTIVE/IDLE. I used ide_cmd_wait() to issue
> > > > > commands like WIN_IDLEIMMEDIATELY and WIN_STANDBYNOW1. The problem is, a
> > > > > drive in standby mode will automatically awake whenever a disk operation
> > > > > is requested and I need to know the mode change as soon as possible. (So I
> > > >
> > > > AFAIK there's no nice way to get that info, but it is useful, so
> > > > patch would be welcome.
> > >
> > > I would check the hdparm man page again. Still, it sounds interesting.
> > >
> > > Additionally, it could be cool if someone could finish up or make the option
> > > for the HD freeze to use it with the HDAPS driver. ;-)
> > >
> > > .Alejandro
> > >
> >
> > Thanks for reply :) What I did to handle this problem is a little stupid
> > : Suppose the disk is now in a standby mode. In case that there is a
> > request sent to the disk drive, a kernel thread is awake to detect/update
> > the current disk power mode. The disk power mode is stored in the
> > ide_drive_t structure and be protected by lock. It seems to work fine in
> > my simple tests. But again, there should be better solutions.
>
> Can we get the patch?
> --

Sure. I will make the patch and test it again. But it may take a while
because I have an urgent task now...Thanks,

Hui