public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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);

  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