| 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
| ||
|
Message-ID: <20070417165759.GA10145@one.firstfloor.org> Date: Tue, 17 Apr 2007 18:57:59 +0200 From: Andi Kleen <andi@...stfloor.org> To: John Sigler <linux.kernel@...e.fr> Cc: Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org Subject: Re: Disabling x86 System Management Mode On Tue, Apr 17, 2007 at 06:49:09PM +0200, John Sigler wrote: > >>.globl foo > >>foo: > >> push %ebx > >> push %esi > >> cpuid > >> rdtsc > > > >At least some SMM implementations restore the old TSC value. Sad but true. > > Why would they do that? I asked the same question. But it has been observed. > How would you detect periodic SMM on such a system? It's not a design goal of SMM to be detectable so the BIOS writers and hardware designers don't care if you can. You could probably try to measure using a external or the LAPIC clock. Or check the chipset bits. > > >Besides RDTSC can be speculated around on some CPUs which also adds errors. > > I don't understand this sentence. Could you clarify? Modern x86 CPUs execute code out of order and in parallel. The reordering window can be quite large and the CPU can execute code speculatively. This can add large errors to RDTSC when the instruction is not executed where you think it is. One way around this is to synchronize it -- using CPUID -- but that also adds latency and makes the measurement less precise. -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/
Powered by blists - more mailing lists