From: John Sigler <linux.kernel@free.fr>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-kernel@vger.kernel.org, linux.kernel@free.fr
Subject: Re: Disabling x86 System Management Mode
Date: Tue, 17 Apr 2007 18:49:09 +0200 [thread overview]
Message-ID: <4624FA85.9010704@free.fr> (raw)
In-Reply-To: <p73odlo55q2.fsf@bingen.suse.de>
[-- Attachment #1: Type: text/plain, Size: 3740 bytes --]
Andi Kleen wrote:
> Please use a full real name for posting.
OK.
> John Sigler wrote:
>
>> AFAIU, even a hard real-time OS is "defenseless" against SMIs that
>> kick the CPU into SMM.
>
> There are usually chipset specific bits that can be set to disable SMMs.
> See the datasheet if you can get them. Unfortunately most chipset vendors
> don't give out data sheets easily.
I've asked the manufacturer to send me the data sheets.
We'll see how they react.
>> .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?
How would you detect periodic SMM on such a system?
> Besides RDTSC can be speculated around on some CPUs which also adds errors.
I don't understand this sentence. Could you clarify?
I've attached my kernel module (hello.c)
# : >/var/log/kern.log; cat /proc/interrupts; /bin/time insmod houba.ko;
cat /proc/interrupts; rmmod houba
CPU0
0: 519083 XT-PIC-XT timer
2: 0 XT-PIC-XT cascade
9: 0 XT-PIC-XT acpi
10: 9786 XT-PIC-XT eth0
11: 5 XT-PIC-XT eth1
12: 5 XT-PIC-XT eth2
14: 16920 XT-PIC-XT ide0
NMI: 0
ERR: 0
0.00user 0.00system 5:00.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+111minor)pagefaults 0swaps
CPU0
0: 549094 XT-PIC-XT timer
2: 0 XT-PIC-XT cascade
9: 0 XT-PIC-XT acpi
10: 9791 XT-PIC-XT eth0
11: 5 XT-PIC-XT eth1
12: 5 XT-PIC-XT eth2
14: 16970 XT-PIC-XT ide0
NMI: 0
ERR: 0
(HZ=100)
30011 timer interrupts
5 eth0 interrupts
50 ide0 interrupts
# cat /var/log/kern.log
Apr 17 18:22:27 SEND kernel: INIT
Apr 17 18:27:27 SEND kernel: 2350080 29995
Apr 17 18:27:27 SEND kernel: 2369792 1
Apr 17 18:27:27 SEND kernel: 2440192 1
Apr 17 18:27:27 SEND kernel: 2441216 1
Apr 17 18:27:27 SEND kernel: 2583296 1
Apr 17 18:27:27 SEND kernel: 2852096 1
Apr 17 18:27:27 SEND kernel: EXIT
First column is the cycle count clamped to a multiple of 256.
(1266.7 MHz CPU)
Second column is occurence count.
In the second experiment, I added the IRQ disable/enable around foo.
# : >/var/log/kern.log; cat /proc/interrupts; /bin/time insmod houba.ko;
cat /proc/interrupts; rmmod houba
CPU0
0: 583666 XT-PIC-XT timer
2: 0 XT-PIC-XT cascade
9: 0 XT-PIC-XT acpi
10: 10084 XT-PIC-XT eth0
11: 5 XT-PIC-XT eth1
12: 5 XT-PIC-XT eth2
14: 17012 XT-PIC-XT ide0
NMI: 0
ERR: 0
0.00user 0.01system 5:00.00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+110minor)pagefaults 0swaps
CPU0
0: 613677 XT-PIC-XT timer
2: 0 XT-PIC-XT cascade
9: 0 XT-PIC-XT acpi
10: 10089 XT-PIC-XT eth0
11: 5 XT-PIC-XT eth1
12: 5 XT-PIC-XT eth2
14: 17070 XT-PIC-XT ide0
NMI: 0
ERR: 0
30011 timer interrupts
5 eth0 interrupts
58 ide0 interrupts
# cat /var/log/kern.log
Apr 17 18:33:12 SEND kernel: INIT
Apr 17 18:38:12 SEND kernel: 2350080 30000
Apr 17 18:38:12 SEND kernel: EXIT
In this experiment, all the calls to foo had a latency between
2350080 and 2350335 cycles (1.88528 to 1.88548 ms).
I don't think I can conclude anything based on this experiment.
I'll let it run all night long.
Regards.
[-- Attachment #2: hello.c --]
[-- Type: text/plain, Size: 938 bytes --]
#include <linux/init.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/slab.h>
MODULE_LICENSE("GPL");
#define N 30000
#define MAX 20000
extern unsigned foo(void);
static int hello_init(void)
{
int i;
int *lat;
printk(KERN_ALERT "INIT\n");
lat = kmalloc(MAX * sizeof *lat, GFP_KERNEL);
if (lat == NULL) return -1;
for (i=0; i < MAX; ++i) lat[i] = 0;
for (i=0; i < 5; ++i) foo();
for (i=0; i < N; ++i)
{
unsigned count, res;
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(1);
foo();
local_irq_disable();
count = foo();
local_irq_enable();
res = count >> 8;
if (res < MAX) ++lat[res]; else printk(KERN_ALERT "OUT OF RANGE\n");
}
for (i=0; i < MAX; ++i)
if (lat[i] != 0) printk(KERN_ALERT "%d %d\n", i<<8, lat[i]);
return 0;
}
static void hello_exit(void)
{
printk(KERN_ALERT "EXIT\n");
}
module_init(hello_init);
module_exit(hello_exit);
next prev parent reply other threads:[~2007-04-17 16:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-16 10:47 Disabling x86 System Management Mode John
2007-04-16 11:31 ` John
2007-04-16 15:12 ` Lee Revell
2007-04-16 22:12 ` Andi Kleen
2007-04-17 16:49 ` John Sigler [this message]
2007-04-17 16:57 ` Andi Kleen
2007-04-17 21:32 ` John Sigler
2007-04-17 17:01 ` John Sigler
2007-04-18 8:09 ` John Sigler
2007-04-18 11:41 ` John Sigler
2007-04-18 14:06 ` Andrew Shewmaker
2007-04-18 14:39 ` John Sigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4624FA85.9010704@free.fr \
--to=linux.kernel@free.fr \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox