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

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

On Fri, Nov 24, 2000 at 09:15:39AM +0900, NIIBE Yutaka wrote:
> Philipp Rumpf wrote:
>  > On Thu, Nov 23, 2000 at 04:50:26PM +0000, David Howells wrote:
>  > > > user code to emulate unaligned accesses, which can be written as someone
>  > > > actually found a userspace programs that needs them.
>  > > 
>  > > We have the code anyway to fix up kernel accesses.
>  > 
>  > no.  we have the code for the few insns actually used by the kernel, and it
>  > can go away as soon as someone convinced DaveM having the network stack use
>  > unaligned accesses is silly.
> 
> I also think that supporting kernel unaligned access is not good idea,
> but Jesper said that DoS possibility (we should check), which I care.

We currently need kernel unaligned accesses for weird network protocols;
there's also a remote exploit possibility.  As for the DoS, I think what
Jesper meant was that if you do emulate unaligned accesses, userspace can
keep doing kernel->user->kernel transitions, which is true anyway.

>  > Do it correctly or don't do it at all.  "We emulate all unaligned memory
>  > accesses except 3 or 4 we didn't bother with" isn't a sensible rule.
> 
> Agreed.
> 
> I installed the patch hoping we could do it correctly.  If it's
> difficult, and we can't see enough rationale about DoS possibility,
> it's better to drop the kernel unaligned access support.

I think we have four groups of accesses we might emulate or not:
1. kernel accesses to kernel memory
2. kernel accesses to user memory
3. user accesses to user memory, using "standard" instructions
4. user accesses to user memory, using non-standard instructions

We definitely need to emulate 1) - at least unless someone convinces the
network guys to drop that requirement.

I don't think we need to emulate 2) - there is nothing wrong, I think, with
returning -EFAULT for unaligned user space pointers passed to syscalls that
try get_user or put_user (we'd lose the atomicity anyway).

Emulating 2) adds some bloat to the unaligned access handler (__copy_user
instead of memcpy).

I don't think we need to emulate 3) either, and I think it's a terrible
precedent to emulate 3) but not 4);  emulating 3) adds yet another bit
of bloat to the unaligned access handler (copy_*_user instead of
__copy_user).  emulating 4) means adding support for many new instructions,
and I'm not sure all of them can be emulated satisfactorily.

> Local user access is more likely than network attack.  Network attack
> can be handled by other devices and feature (router, firewall rules), 
> so we should have more care for local user access.

I don't think there are any security holes left in the patch posted
yesterday (which emulates 1, 2, and 3), but I need to have another look.