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

[Philipp R. <pr...@pa...>]

On Thu, Nov 23, 2000 at 02:28:57PM +0000, David Howells wrote:
> 
> > and adds unaligned userspace access emulation, which I still think is a
> > terribly bad idea;
> 
> insmod can do this a lot.

fix insmod.  it seems to work on other architectures that don't support
unaligned accesses.

> > 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.

at which point the kernel unaligned emulation code will become larger than
the kernel-only + user code combined, I think.  and definitely slower.
> 
> > 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.

why "EFAULT" ?.  EFAULT means "a system call couldn't access user data
necessary to complete successfully".  What we have here is "we tried to
access unmapped/inappropriately mapped data".  In particular EFAULT is
definitely inappropriate when you mean SIGSEGV.

> > 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.

it just means your comment is wrong.