Re: [linuxsh-dev] Re: bad alignment fixup

[David H. <dho...@re...>]

> and adds unaligned userspace access emulation, which I still think is a
> terribly bad idea;

insmod can do this a lot.

> it also adds at least several security holes:
> 1. accesses to [0x80000000,0xffffffff] generate address errors while in
> userspace.
> 2. if the faulting insn is just before 0x80000000, we must not access memory
> after 0x80000000 to fetch data.
> 3. unaligned accesses to [0x80000000,0xffffffff] get emulated

Good point... I'll fix it and also add this to my test program.

> what's the rationale for the -EFAULT return value here ?  All the
> information is already there, and we don't know enough about the context
> to decide whether we're in a -EFAULT situation at all.

Because otherwise the calling function would have to do call die_if_no_fixup()
and then return -EFAULT in two operations. This way we can make use of gcc's
tail-recursion optimisation.

> same here ..

Firstly, because handle_unaligned_ins() needs to tell its caller whether it
succeeded or not when fixing up branch-delay-slot faults (since the branch
should not be emulated if the fixup failed), and secondly so that
do_address_error() can be told whether to issue a SEGV or not when userspace
faults.

> Isn't this what happens when you jsr to an address in the top two GB ?

Sort of, but in userspace, this doesn't matter since it will be handled
separately upon return.

> yuck, see CodingStyle ;)

I know, I know, but I generally prefer to move the else so that it isn't
directly adjacent to the text on the line above (particularly so with
else-if's).

David