public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Richard B. Johnson" <root@chaos.analogic.com>,
	richardj_moore@uk.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: Why is double_fault serviced by a trap gate?
Date: Thu, 7 Dec 2000 20:20:22 MET-1	[thread overview]
Message-ID: <F02E6C85A2D@vcnet.vc.cvut.cz> (raw)

On  7 Dec 00 at 19:04, Maciej W. Rozycki wrote:
> On Thu, 7 Dec 2000, Petr Vandrovec wrote:
> 
> > No. If interrupt uses task gate, task switch happens. Nothing is stored
> > in context of old process except registers into TSS. There is only one
> > (bad) problem. If you want to get it 100% proof (it is not needed for double
> > fault, but it is definitely needed for NMI, as NMI is very often on SMP
> > ia32), each CPU's IRQ vector must point to different task, otherwise you
> > can get TSS in use during doublefault, leading to triplefault again...
> 
>  Well, I expect wasting a descriptor and a page of memory for the purpose
> of a TSS is not a big problem.

It is architectural problem. Each CPU must have its own IDT or GDT table.
If (for real example) you'll use task gate for NMI, both NMIs are currently
(AFAIK) delivered to both CPUs at same time. Both CPUs find in IDT that
they should switch to task 0x1230. So one of them finds TSS 0x1230 (in GDT
entry 0x1230 / 8) as not busy (busy is field in TSS GDT descriptor), marks 
it busy and starts executing in new context. But other one finds 0x1230 as 
busy. And fault during doublefault is triplefault. Which is hardwired to 
reset and we are where we were before...

<fiddling through manuals>

Well, Intel recommends 'Invalid TSS' exception to be handled through TSS
too, for obvious reason that CPU state may be half-old and half-new...
But I'm not sure that all vendors handle TSS fault during doublefault
correctly and I do not want to rely on that. 

So either each CPU must have its own IDT, pointing to different slots
in GDT, or each CPU must have its own GDT... I preffer IDT, as having
per-CPU GDT could create some really nasty problems (f.e. synchronizing
LDT entries between CPUs) (*) (**).

> > Yes. Currently if any ESP related problem happens in kernel, machine silently
> > reboots without any message. With task gate (as Jeff Merkey proposed
> 
>  You might handle the stack fault with a task gate, actually, but I'm not
> sure it's worth the hassle.  Handling just the double fault should be
> sufficient. 

Yes, it is. Directing stackfault to task gate is wrong, as userspace
faults ar handled by stackfault. Most of kernelspace stackfaults are 
handled by doublefault ;-)

                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
                                            
(*) I have even per-process IDT patch at 
ftp://platan.vc.cvut.cz/pub/linux/idt/idts-0.00.tar.gz, so per-cpu
IDTs should be doable too... Patch is for 2.3.11-pre3, so it will
need some tweaking if someone wants to try it...

(**) On other hand, it could allow leaking information. Currently
you can find on which CPU you run with:

void main(void) {
    int x;
    
    while (1) {
        asm ( "str %%ax\n" : "=a"(x));
        printf("CPU %u\n", (x - 0x60) / 0x20);
    }
}

With per-CPU GDT we could have same value of TR accross all CPUs...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-12-07 19:52 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-07 20:20 Petr Vandrovec [this message]
2000-12-07 19:38 ` Why is double_fault serviced by a trap gate? Maciej W. Rozycki
  -- strict thread matches above, loose matches on Subject: below --
2000-12-09 23:46 richardj_moore
2000-12-08 20:48 richardj_moore
2000-12-08 16:34 richardj_moore
2000-12-08 16:52 ` Richard B. Johnson
2000-12-08 13:18 richardj_moore
2000-12-08  8:37 richardj_moore
2000-12-08 12:58 ` Richard B. Johnson
2000-12-08 22:34   ` Keith Owens
2000-12-08 20:31 ` Mikulas Patocka
2000-12-07 23:08 richardj_moore
2000-12-07 23:03 richardj_moore
2000-12-07 23:01 Petr Vandrovec
2000-12-07 21:09 richardj_moore
2000-12-07 21:44 ` Richard B. Johnson
2000-12-07 22:36   ` Brian Gerst
2000-12-08  1:36     ` Richard B. Johnson
2000-12-08 11:44       ` Maciej W. Rozycki
2000-12-07 22:47 ` Keith Owens
2000-12-08 11:30 ` Maciej W. Rozycki
2000-12-07 18:13 Petr Vandrovec
2000-12-07 18:04 ` Maciej W. Rozycki
2000-12-07 16:04 richardj_moore
2000-12-07 16:13 ` Andi Kleen
2000-12-07 16:31   ` Richard B. Johnson
2000-12-07 16:55   ` Maciej W. Rozycki
2000-12-07 18:05     ` Andi Kleen
2000-12-07 18:11       ` Maciej W. Rozycki
2000-12-07 18:29         ` Andi Kleen
2000-12-07 18:47           ` Maciej W. Rozycki

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=F02E6C85A2D@vcnet.vc.cvut.cz \
    --to=vandrove@vc.cvut.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=richardj_moore@uk.ibm.com \
    --cc=root@chaos.analogic.com \
    /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