> >>>We will never be doing this: it violates the safety constraint, in
> >>>several dimensions. (One of which you outline below.)
> >>I'm interested - which other dimensions do you have in mind?
> >
> >What if someone puts bad ECC on the text or data required to execute
> >the bad ECC handler? How does DTrace know what this text and data are
> >to prohibit it?
>
> Sorry - I wasn't clear. "Someone" here is Dtrace; I'm suggesting
> that Dtrace should both place the bad-ECC and log the placed regions.
No, you were being perfectly clear -- you're just not understanding
what I'm saying. DTrace is but a conduit; assuming you're going to allow
programmability around this, you will be allowing users to put bad ECC
on arbitrary memory. Offering this programmability introduces all of the
issues that I mentioned.
> > More generally, what if someone puts bad ECC on text
> >or data that needs to be accessed at TL>1? How is this handled?
>
> Yes, that is an issue. Can we constrain it in any way? What memory
> is accessed at TL>1, and can we restrict it from this type of
> tracing?
I'm not going to give you a tutorial on SPARC; suffice it to say that
this is an extraordinarily difficult problem to bound or solve -- and
the failure mode is fatal, which means the solution must not be brittle.
It's very hard to see how one could constrain or know the memory accessed
in illegal contexts in a way that was sufficiently robust.
But I'm not going to have an extended discussion about this idea; it's
fatally flawed (at least from the DTrace perspective), for the reasons
that I have already expanded on.
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
_______________________________________________
networking-discuss mailing list
[email protected]
