linux-kernel - Re: [tip:sched/core] sched: Lower chances of cputime scaling overflow

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]

Message-ID: <20130326165433.GC2029@redhat.com>
Date:	Tue, 26 Mar 2013 17:54:33 +0100
From:	Stanislaw Gruszka <sgruszka@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, hpa@...or.com, rostedt@...dmis.org,
	akpm@...ux-foundation.org, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [tip:sched/core] sched: Lower chances of cputime scaling overflow

On Tue, Mar 26, 2013 at 03:19:25PM +0100, Frederic Weisbecker wrote:
> I starred at that code for quite some time already and I can't come up
> with a better solution.
> 
> Of course 128 bits ops are very expensive, so to help you evaluating
> the situation, this is going to happen on every call to
> task_cputime_adjusted() and thread_group_adjusted(), namely:
> 
> * Some proc files read
> * sys_times()
> * thread group exit

I need to think if we can get rid of thread_group_cputime_adjusted()
at exit(), perhaps this is possible without causing problems.

Div128 is optimized if higher 64-bits are zeros. 128 bit multiplication
can be avoided if we are sure that 64bit mul will not overflow, for
example:

if (ffs(stime) + ffs(rtime) < 64)
	scale_64()
else
	scale_128()

Basically 99.9% of processes will go scale_64() path. Fix is only
needed for processes that utilize lot of CPU time for long period,
hence have big stime and rtime values, what is not common.

I'm thinking also about remove cputime scaling. Obviously this would
be the best regarding performance. I think we could avoid multiplication
in kernel, this can be done in user-space if we export rtime to it.
So top could be modified to do cputime scaling by itself. In that way
we will avoid this top hiding "exploit", but also precision of times(2)
syscall values will get worse (I think there are lot of programs that
use this call and they might expect stime/utime are precise).

Stanislaw

--
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/