| 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
| ||
|
Date: Wed, 7 Apr 2010 14:53:18 -0400 From: Joe Korty <joe.korty@...r.com> To: Randy Dunlap <randy.dunlap@...cle.com> Cc: Ingo Molnar <mingo@...e.hu>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de> Subject: [PATCH] Tweak SMI sniffer commentary On Wed, Apr 07, 2010 at 02:05:07PM -0400, Randy Dunlap wrote: > > + to detect otherwise undetectable SMIs. Not available > > + unless CONFIG_DEBUG_SMI_SNIFFER=y. > > preferable: Only available when CONFIG_DEBUG_SMI_SNIFFER=y. > drop "to" (redundant) ^^ > s/cpu/CPU/ throughout > drop "to" (redundant) > s/ie/i.e./ > > +the applications running underneath it. For many uses this is unimportant, > (or on top of it ;) > > +their occurrence via the setting of a per-cpu 'system interrupt occured' flag. > occurred Hi Randy, Thanks! I've created a follow-on patch containing the suggested rewordings. Joe [PATCH] Tweak some SMI sniffer commentary Thanks go to Randy Dunlap for these suggestions. Signed-off-by: Joe Korty <joe.korty@...r.com> Index: 2.6.34-rc3/Documentation/kernel-parameters.txt =================================================================== --- 2.6.34-rc3.orig/Documentation/kernel-parameters.txt 2010-04-05 14:30:06.000000000 -0400 +++ 2.6.34-rc3/Documentation/kernel-parameters.txt 2010-04-07 14:39:50.000000000 -0400 @@ -947,8 +947,8 @@ will use a lot of power and make the system run hot. Not recommended. idle=smi: variant of idle=poll that uses the spin-time - to detect otherwise undetectable SMIs. Not available - unless CONFIG_DEBUG_SMI_SNIFFER=y. + to detect otherwise undetectable SMIs. Only available + when CONFIG_DEBUG_SMI_SNIFFER=y. idle=mwait: On systems which support MONITOR/MWAIT but the kernel chose to not use it because it doesn't save as much power as a normal idle loop, use the Index: 2.6.34-rc3/Documentation/x86/smi-sniffer.txt =================================================================== --- 2.6.34-rc3.orig/Documentation/x86/smi-sniffer.txt 2010-04-05 14:30:06.000000000 -0400 +++ 2.6.34-rc3/Documentation/x86/smi-sniffer.txt 2010-04-07 14:49:19.000000000 -0400 @@ -8,17 +8,17 @@ interrupt that goes directly to the BIOS. They are used by motherboard manufacturers to, for example, 1) simulate missing hardware in software, such as an RTC or emulating a missing PS2 mouse/keyboard using a USB -mouse/keyboard, 2) to perform critical motherboard duties, such as periodic -DRAM memory refresh or slowing the cpu down whenever it gets too hot, and 3) -to work around in software (ie, in the BIOS) deficiencies discovered after +mouse/keyboard, 2) perform critical motherboard duties, such as periodic +DRAM memory refresh or slowing the CPU down whenever it gets too hot, and 3) +work around in software (i.e., in the BIOS) deficiencies discovered after a board has been manufactured and shipped to customers. The OS is not involved with nor even informed of these interrupts when they occur, and indeed it is difficult for the OS to detect that they have occurred at all. The only signature an SMI leaves behind is the time that it -consumes. These 'time slices', taken randomly out of the running time of a cpu, +consumes. These 'time slices', taken randomly out of the running time of a CPU, compromise the ability of the OS to provide reasonable latency guarantees to -the applications running underneath it. For many uses this is unimportant, +the applications running on top of it. For many uses this is unimportant, but for real time systems, the occurrence of an SMI during the run of some critically-timed piece of code could shatter the correct running of the system. @@ -36,8 +36,8 @@ routine is in use, by an "echo 1 >/proc/sys/kernel/smi_sniffer_enable" command. The sniffer adds a pair of lines to /proc/interrupts. The "SMI" line shows -the number of SMIs detected (per-cpu) so far. The "DSMI" line gives the -duration, in microseconds, of the most recent SMI (for each cpu). +the number of SMIs detected (per-CPU) so far. The "DSMI" line gives the +duration, in microseconds, of the most recent SMI (for each CPU). These lines appear only while the sniffer is running. If it is disabled later, say with an "echo 0 >/proc/sys/kernel/smi_sniffer_enable", then the lines @@ -66,7 +66,7 @@ longer than 125 usecs by the time it took to process the interrupt. The OS is modified so that all normal system interrupts, including NMI, mark -their occurrence via the setting of a per-cpu 'system interrupt occured' flag. +their occurrence via the setting of a per-CPU 'system interrupt occurred' flag. We can therefore detect SMIs by assuming that if a period significantly longer than 125 usecs is seen, and this 'system interrupt happened' flag is not set, that it was an SMI that lengthened the period. -- 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