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]

Message-ID: <a2ebde260609290916j3a3deb9g33434ca5d93e7a84@mail.gmail.com>
Date:	Sat, 30 Sep 2006 00:16:07 +0800
From:	"Dong Feng" <middle.fengdong@...il.com>
To:	"Christoph Lameter" <clameter@....com>
Cc:	"Andi Kleen" <ak@...e.de>, "Nick Piggin" <nickpiggin@...oo.com.au>,
	"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/9/30, Christoph Lameter <clameter@....com>:
> On Fri, 29 Sep 2006, Dong Feng wrote:
>
> > For my understanding, an assignment between structs should be a
> > bit-wise copy. Such operation is not atomic, so it can not be supposed
>
> Byte or Machine word yes.
>
> > SMP-safe. And the subsequent test-and-assign operation on firsttime is
> > not atomic, either.
>
> No its not atomic on its own. Correct.
>
> > If the comments mean the subsequent code is SMP-safe and can prevent
> > nest-kernel-path, how does it achieves that?
>
> It relies on locking outside of do_sys_settimeofday(). Seems that this
> indicates locking is to be performed by the arch before calling
> do_sys_settimeofday. Looks suspicious to me. Check that this function is
> always called with the same lock.
>

Yes, that is the question. The whole invocation path is
sys_settimeofday() -> do_sys_settimeofday()

I do not find a lock embracing do_sys_settimeofday().

Moreover, seems neither write operations nor read operations on sys_tz
is protected by any locks, in sys_gettimeofday() and
sys_settimeofday() respectively.
-
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/