From owner-cvs-all Sun May 9 21:25:10 1999 Delivered-To: cvs-all@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 35AD614F33; Sun, 9 May 1999 21:25:07 -0700 (PDT) (envelope-from nsayer@medusa.kfu.com) Received: from medusa.kfu.com (medusa.kfu.com [170.1.70.5]) by quack.kfu.com (8.9.2/8.8.5) with ESMTP id VAA28646; Sun, 9 May 1999 21:25:06 -0700 (PDT) Received: (from nsayer@localhost) by medusa.kfu.com (8.9.2/8.8.8) id VAA24216; Sun, 9 May 1999 21:25:05 -0700 (PDT) (envelope-from nsayer) From: Nick Sayer Message-Id: <199905100425.VAA24216@medusa.kfu.com> Subject: Re: cvs commit: src/sys/kern kern_time.c In-Reply-To: <199905100043.KAA08334@godzilla.zeta.org.au> from Bruce Evans at "May 10, 1999 10:43:44 am" To: bde@zeta.org.au (Bruce Evans) Date: Sun, 9 May 1999 21:25:05 -0700 (PDT) Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, nsayer@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > Modified files: (Branch: RELENG_3) > > sys/kern kern_time.c > > Log: > > MFC: securelevel time setting handling code. This has worked > > perfectly on a number of RELENG_3 machines since it was added > > to -current. > > This should be backed out of both -current and RELENG_3. **SIGH** We went through this and through this and through this. > Only the part > that disallows setting the clock forward is correct. Bugs in the other > parts include: > > - success is returned after clamping the time to a time other than the > one requested. That can be fixed without having the fix "backed out of both -current and RELENG_3". > - error messages about clamping are printed at splhigh(). That can be fixed without having the fix "backed out of both -current and RELENG_3". > An application can only avoid these problems by being fairly aware of > the implementation and doing micro-adjustments, but micro-adjustments > can be done better using adjtime(2), modulo the reluctance of adjtime() > to adjust the time rapidly. Fine. Then YOU fix xntpd so that it doesn't do EXACTLY AS YOU DESCRIBE, in that when the adjustment is too large it switches to making smallish calls to settimeofday(). Then we can just plain outlaw settimeofday() when securelevel>0. In the mean time, the code in question makes xntpd not FAIL COMPLETELY on systems running with securelevel>0, it actually WORKS in that it prevents what the previous code did not -- setting the clock to a value in the past (it was possible to set the clock forward twice and get into the past by wrapping a clock_t). Egads! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message