Re: [PATCH -tip 0/4] do not make cputime scaling in kernel

[Ingo Molnar <mingo@kernel.org>]

* Frederic Weisbecker <fweisbec@gmail.com> wrote:

> 2013/4/4 Stanislaw Gruszka <sgruszka@redhat.com>:
> > On Thu, Apr 04, 2013 at 02:31:42PM +0200, Frederic Weisbecker wrote:
> >> I don't know. I'm not convinced userland is the right place to perform
> >> this kind of check. The kernel perhaps doesn't give guarantee about
> >> utime/stime precision but now users may have got used to that scaled
> >> behaviour. It's also a matter of security, a malicous app can hide
> >> from the tick to make its activity less visible from tools like top.
> >>
> >> It's sortof an ABI breakage to remove such an implicit protection. And
> >> fixing that from userspace with a lib or so won't change that fact.
> >
> > I think number of fields in /proc/PID/stat is not part of ABI. For
> > example commit 5b172087f99189416d5f47fd7ab5e6fb762a9ba3 add various
> > new fields at the end of the file. What is imported to keep unchanged
> > ABI is not changing order or meaning of fields we already have.
> 
> Oh I wasn't considering the layout of the proc file but the semantic
> change in its utime/stime fields.

Btw., even the ordering of fields in /proc/PID/stat might be an ABI, iif an 
application relies on it and breaks if we change it.

What matters is what applications do, not what we think they do or what we think 
they should do in an ideal world.

> > Regarding top, I added those additional fields to allow top to detect those 
> > malicious software. Patched top will work well with old and new (patched) 
> > kernel. Problem is old top with new kernel, but I believe users who care about 
> > security update they software regularly.
> 
> The usual rule is that but you can't remove a feature from the kernel and tell 
> userspace to fix it itself. That's basically an ABI breakage.

Correct.

Thanks,

	Ingo