Deutsch   English   Français   Italiano  
<v464c4$73tb$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Terje Mathisen <terje.mathisen@tmsw.no>
Newsgroups: comp.arch
Subject: Re: Privilege Levels Below User
Date: Mon, 10 Jun 2024 07:53:08 +0200
Organization: A noiseless patient Spider
Lines: 81
Message-ID: <v464c4$73tb$1@dont-email.me>
References: <jai66jd4ih4ejmek0abnl4gvg5td4obsqg@4ax.com>
 <Z9I8O.13$2JEf.11@fx14.iad> <5h%8O.4327$wDZ.776@fx48.iad>
 <v428v9$2o803$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 10 Jun 2024 07:53:08 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="61a4720bc8db2ac0344820afeea0b6ea";
	logging-data="233387"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1872yKBR/BQGwFOvCd00fd5e2Ff22R+hOj7EdtuyLPDQw=="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:wLj57gVq9R5ojVa15o1KBPku0nc=
In-Reply-To: <v428v9$2o803$1@dont-email.me>
Bytes: 4007

BGB wrote:
> Though, there are some instructions which are currently allowed in user=
=20
> mode but which it could make sense to trap in some contexts, such as=20
> CPUID, or potentially just parts of CPUID, ...
>=20
> Say, for example, CPUID has several pieces of information available:
>  =C2=A0 CPU type and features;
>  =C2=A0 Microsecond timer (local);
>  =C2=A0 Clock cycle timer;
>  =C2=A0 Hardware RNG;
>  =C2=A0 ...
>=20
> In various contexts, it may be reasonable to want to trap and emulate=20
> some of these while still allowing others to be unhindered.

Yeah.
>=20
> Though, the time returned by the CPUID microsecond timer is not=20
> currently the same as the one given by "TK_GetTimeUS()", where the=20
> latter effectively gives a 64-bit value (conceptually) representing the=
=20
> number of microseconds since 1/1/1970; though with the kernel currently=
=20
> assuming that its build-time is the starting time for the clock (and=20
> none of the FPGA boards support a hardware clock, and one would need=20
> internet access to use NTP, ...).
>=20
> A 64-bit value in microseconds can express around +/- 300k years, which=
=20
> should be plenty.

Experience have shown that microsecond resolution is NOT good enough,=20
i.e. GPS timing receivers can typically give you ~25 ns RMS accuracy for =

less than $100.

WinNT settled on 64-bit 100 ns ticks from 1600-01-01, that has turned=20
out to be pretty good, but (see above) not quite good enough for all uses=
=2E

Modern Unix typically provides 64-bit time_t seconds and a (effectively) =

30-bit ns field, so you can store them in a 96-bit container but I don't =

think anyone does that?

If you have a lot of such timestamps I would suggest you instead=20
truncate the time_t seconds field to just the classic 32 bits and use=20
windowing around the current (full resolution) time.

>=20
> A 64-bit value expressed in seconds could express values relative to th=
e=20
> current age of the universe, but this is likely unnecessary for most=20
> purposes, and ability to express fractions of a second is likely more=20
> useful than the ability to express the age of the universe.

NTP only needs relative timestamps, so Dr Mills settled on 32-bit=20
seconds (since 1900!) + 32-bit fractions, so NTP timestamps have roughly =

0.25 ns resolution. The latter corresponds to 5 cm of fiber optic=20
transmission delay.
>=20
>=20
> Granted, one could use a 128-bit value, and have both (and in=20
> picoseconds if they wanted). But, this would be overkill.
>=20
> Or, go extra overkill, and use 256 bits, to express the current age of =

> the universe in Planck units...

:-)

Terje


--=20
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"