On Wed, Jul 15, 2009 at 2:43 AM, Arnd Bergmann <[email protected]> wrote:
> On Tuesday 14 July 2009, Michal Simek wrote:
> > Arnd Bergmann wrote:
>
> > >> r29=00000000, r30=00000000, r31=CE9759A4, rPC=C000123C
> > >> msr=800045AE, ear=00000001, esr=000000B2, fsr=000080D0
> > >> Segmentation fault
> > >>
> > >
> > > I guess then you should check if 0xc000123c is in your
> > > exception table, or why it is not.
> >
> > on that address is load instruction for unaligned exception because addr
> is odd number
> > that's why is called unaligned exception handler and from this function
> > is called load instruction which failed. :-(
> >
> > Currently this make more sense why that tests failed. If that pointers
> are
> > even number exception is not taken and exception sure don't have fixup
> for it because
> > this is generic code. :-(
> >
> > That's the problem because we are looking for regs->pc but this point to
> unaligned exception
> > handler.
>
> Ok, that makes a lot of sense.
>
> The solution then is to handle fixups from the unaligned exception handler
> if you come from the kernel. That should fix the three text cases.
>
> I don't fully understand your exception handling there, but I think you
> also need to add code checking for __range_ok() to your unaligned handler,
> to prevent malicious user space code from accessing the kernel through
> unaligned pointers.
Just to try to clarify - are there any alignment rules in the ABI on
user-space pointers (which end up going to get/put_user)?
It seems the failure path is like this:
1. userspace passes unaligned pointer
2. get_user attempts to access
3. CPU raises unaligned exception (if only it would raise the segfault as
higher priority, before the unaligned!)
4. unaligned exception handler attempts to simulate the unaligned access
with multiple partial read/write ops
5. CPU raises MMU exception on the read/write by the unaligned handler
6. kernel segfault handler looks up faulting address, it is in the unaligned
exception handler, which has no fixup.
7. no fixup -> failure
So, I suppose the question is - where in the sequence is the true failure?
Clearly LTP thinks it's ok to pass unaligned pointers to the kernel,
suggesting (1) is fine - thus my question about alignment rules in the ABI.
Do we need fixups on the unaligned handler itself? This will be ugly ugly
ugly. Or, some way of tracing the segfault back through the unaligned
exception and to the root cause (the get/put-user), and call that fixup as
required?
Thanks,
John
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
