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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 1 Oct 2006 20:22:22 +0800
From:	"Dong Feng" <middle.fengdong@...il.com>
To:	"Nick Piggin" <nickpiggin@...oo.com.au>
Cc:	"Christoph Lameter" <clameter@....com>, "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?

2006/10/1, Nick Piggin <nickpiggin@...oo.com.au>:
> It is in an unlikely path though. How many apps actually pass in a
> non NULL value for the timezone? Those that don't won't be affected.
> Even for those that do, it doesn't introduce any atomic ops or
> unpredictable branches, or cacheline pressure (because xtime lock is
> already touched by do_gettimeofday). IOW: I'm sure it would be
> unmeasurable.

I agree the above. Normally the unlikely path is not invoked after boot.

>
> OTOH, to be completely correct, it seems like the same xtime_lock
> read section should cover both the calculation of ktv, and that of
> ktz. So if it is going to be fixed at all, it should be done
> properly and looks like it needs to be a bit more intrusive (but
> no more expensive).
>

That means either 1. Move the seq lock from within do_gettimeofday()
to out of do_gettimeofday(), or 2. pass ktz into do_gettimeofday() and
compute it in the preexisting read section in do_gettimeofday().

The first changes the semantic of do_gettimeofday() so it would be
unacceptable since the function is invoked from many places. The
second changes the signature of the function so every caller need to
be changed to passing an extra NULL pointer in order to satisfy the
changed invocation agreement.

I think the race condition is not unacceptable so long as comments is
changed to state the situation clearly. To move everything into the
same read (and write) section (respectively) is a bit bigger work but
it does not introduce performance penalty at run time. Or perhaps we
could tolerate some middle point, that is, as the initial patch, still
protect ktz and ktv in separated section and let the comments state
the not-so-perfect situation clearly.
-
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/