[okl4-developer] KD# exception delivery error

Jorge Torres jorge.torres.maldonado at gmail.com
Wed Aug 1 13:56:56 EST 2007


Hi Carl, Geoffrey,

Well, I guess that is not a problem with 1.4.1.1 release is it?, anyways, I
wanted to thank you, I changed the send_excemption_ipc() hack and it now
works, here it is (am I missing something?)

static void send_exception_ipc(ia32_exceptionframe_t * frame, word_t
exception, continuation_t continuation)
{
    tcb_t * current = get_current_tcb();
    if (current->get_exception_handler().is_nilthread())
         ACTIVATE_CONTINUATION(continuation);

    current->arch.exception_ipc_continuation = continuation;

    TRACEPOINT_TB (EXCEPTION_IPC,
                   printf ("exception ipc at %x, %T (%p) -> %T \n",
frame->eip, current->get_global_id().get_raw(),
                       current, current->get_exception_handler().get_raw()),
                   "exception_ipc at %x (current=%p)", frame->eip,
(u32_t)current);

    /* setup exception IPC */
    msg_tag_t tag;

    // save message registers
    for (int i = 0; i < 13; i++)
                current->arch.saved_mr[i] = current->get_mr(i);
    current->misc.ipc_copy.saved_notify_mask = current->get_notify_mask ();
    current->set_saved_partner (current->get_partner());
    current->set_saved_state (current->get_state());

    tag.set(12, -5 << 4, true, true);
    current->set_mr(0, tag.raw);
    current->set_mr(1, frame->eip);
    current->set_mr(2, frame->eflags);
    current->set_mr(3, exception);
    current->set_mr(4, frame->error);
    current->set_mr(5, frame->edi);
    current->set_mr(6, frame->esi);
    current->set_mr(7, frame->ebp);
    current->set_mr(8, frame->esp);
    current->set_mr(9, frame->ebx);
    current->set_mr(10, frame->edx);
    current->set_mr(11, frame->ecx);
    current->set_mr(12, frame->eax);

    current->do_ipc(current->get_exception_handler(),
current->get_exception_handler(), finish_exception_ipc);
}

Again,

Thank you very much,

Jorge

On 7/30/07, Carl van Schaik <carl at ok-labs.com> wrote:
>
> This exception handler/scheduler hack is fixed in later versions, but
> I'm not sure whats in the release you are working on. The main reason it
> was in using the exception handler previously was due a security
> concern. In the old API, a thread was able to changes its exception
> handler thread without asking a manager thread. Thus it could use this
> to send IPCs to any thread in the system since the kernel assumes the
> exception handler is the correct thread and thus does not need security
> checks.
>
> --
> Carl
>
> Geoffrey Lee wrote:
> > On Mon, Jul 30, 2007 at 01:02:43PM -0400, Jorge Torres wrote:
> >
> >> Than you very much Geoffrey,
> >>
> >>
> >
> > Hi Jorge
> >
> >
> >
> >> I will try to find where such hack is, but at this moment I can't
> understand
> >> something: when you mean a hack that uses the scheduler for exceptions,
> you
> >> mean that scheduler thread is responsible for its corresponding thread
> >> exemptions?, shouldn't it be thread's handler thread?
> >>
> >>
> >
> > When you receive an exception, it should check to see if there is
> > an exception handler registered and if so use that to fake an IPC
> > to the exception handler.
> >
> > However, due to the hack being there, it uses the registered
> > scheduler handler instead.
> >
> > You are correct, it should use the exception handler not
> > the scheduler to send the exception IPCs.
> >
> > The send_exception_ipc() function is architecture specific, IA-32 seems
> > to use the scheduler (which is probably wrong) while ARM does the right
> > thing.
> >
> >
> >
> >
> >> Thank you very much, and please forgive my ignorance,
> >>
> >> Jorge
> >>
> >>
> >
> >       - gl
> >
> > _______________________________________________
> > Developer mailing list
> > Developer at okl4.org
> > https://lists.okl4.org/mailman/listinfo/developer
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20070731/a1335ea6/attachment.htm 


More information about the Developer mailing list