lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 4 Apr 2013 14:31:42 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Stanislaw Gruszka <sgruszka@...hat.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Paul Turner <pjt@...gle.com>
Subject: Re: [PATCH -tip 0/4] do not make cputime scaling in kernel

2013/4/4 Stanislaw Gruszka <sgruszka@...hat.com>:
> This patch series removes cputime scaling from kernel. It can be easily
> done in user space using floating point if we provide sum_exec_runtime,
> what patches 2/4 and 3/4 do. I have procps patch which utilize that:
>
> http://people.redhat.com/sgruszka/procps-use-sum_exec_runtime.patch
>
> I will post it, if this patch set will be queued.
>
> Change affect also getrusage() and times() syscals, but I don't think
> kernel give guarantees about utime/stime precision, in a matter of fact
> before commit b27f03d4bdc145a09fb7b0c0e004b29f1ee555fa, we do not
> perform any scaling and we provided raw cputime values to user space.
>
> Providing sum_exec_runtime via proc is done against malware that utilize
> lot of cpu time but hide itself from top program.
>
> This affect kernels not compiled with CONFIG_VIRT_CPU_ACCOUNTING_{GEN,NATIVE},
> if user choose to compile kernel with some of those options, he/she will
> have more precise cputime accounting, what is documented in Kconfig.
>

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.

How about that 128bits based idea? I'm adding Paul Turner in Cc
because he seemed to agree with doing it using 128bits maths.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ