linux-kernel - Re: How is Code in do_sys_settimeofday() safe in case of SMP and Nest Kernel Path?

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0609301015060.3519@schroedinger.engr.sgi.com>
Date:	Sat, 30 Sep 2006 10:26:06 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Dong Feng <middle.fengdong@...il.com>
cc:	Nick Piggin <nickpiggin@...oo.com.au>, Andi Kleen <ak@...e.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Paul Mackerras <paulus@...ba.org>,
	David Howells <dhowells@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: How is Code in do_sys_settimeofday() safe in case of SMP and
 Nest Kernel Path?

On Sun, 1 Oct 2006, Dong Feng wrote:

> --- kernel/time.c.orig	2006-09-30 23:21:29.000000000 +0800
> +++ kernel/time.c	2006-09-30 23:38:18.000000000 +0800
> @@ -107,7 +107,16 @@ asmlinkage long sys_gettimeofday(struct
> 			return -EFAULT;
> 	}
> 	if (unlikely(tz != NULL)) {
> -		if (copy_to_user(tz, &sys_tz, sizeof(sys_tz)))
> +		struct timezone ktz;
> +		unsigned long seq;
> +
> +		do {
> +                	seq = read_seqbegin(&xtime_lock);
> +			ktz.tz_minuteswest = sys_tz.tz_minuteswest;
> +			ktz.tz_dsttime = sys_tz.tz_dsttime;
> +        	} while (unlikely(read_seqretry(&xtime_lock, seq)));
> +
> +		if (copy_to_user(tz, &ktz, sizeof(ktz)))
> 			return -EFAULT;

I really hate adding overhead to gettimeofday() and we would have to take 
the seqlock in all places when we reference tz. Maybe we can tolerate the 
resulting race?

If we assume word size transfers then we only have an issue on 32 bit 
platforms. The result of the race would be that tz_minuteswest and 
tz_dsttime disagree. So we may get daylight savings time wrong.
But then we are already changing the timezone and are potentially warping time.
gettimofday may be unstable anyways. So it may be okay to leave the race 
in. Just add some comments explaining the situation.
-
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/