linux-kernel - Re: [PATCH 1/2] Make the TSC safe to be used by gettimeofday().

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: <200611140344.00407.ak@suse.de>
Date:	Tue, 14 Nov 2006 03:44:00 +0100
From:	Andi Kleen <ak@...e.de>
To:	Suleiman Souhlal <ssouhlal@...ebsd.org>
Cc:	Linux Kernel ML <linux-kernel@...r.kernel.org>, vojtech@...e.cz,
	Jiri Bohac <jbohac@...e.cz>
Subject: Re: [PATCH 1/2] Make the TSC safe to be used by gettimeofday().


> 
> Because CPUID returns the APIC ID, and I was under the impression that 
> the cpu numbers
> smp_processor_id() were dynamically allocated and didn't necessarily 
> match the
> APIC ID.

Correct, but one can use a mapping table.


> Yes, it's only needed on HLT and cpufreq change.
> The code here is to force a "resynch" with the HPET if we've done a HLT. 
>   It has to be done before we switch to any userland thread that might 
> use the per-cpu vxtime. switch_to() seemed like the most natural place 
> to put this.

I don't think so. The natural place after HLT is in the idle loop or 
better in idle notifiers[1] and after  cpufreq is in the appropiate cpufreq 
notifiers.
 

[1] unfortunately they are still subtly broken in .19, but will be fixed
in .20

> A cow-orker suggested that we use SIDT and encode the CPU number in the 
> limit of the IDT, which should be even faster than LSL.

Possible yes. Did you time it?

But then we would make the IDT variable length in memory? While
the CPUs probably won't care some Hypervisors seem to be picky
about these limits. LSL still seems somewhat safer.
 
> I couldn't figure out how to tell if a context switch has happened from 
> userland. I tried putting a per-cpu context switch count, but I couldn't 
> figure out how to get it atomically along with the CPU number..

It's tricky. That is why we asked for RDTSCP.

-Andi
-
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/