Re: [PATCH] Some fixes for compat ioctl

[Michael S. Tsirkin]

Hi, Andi!

Quoting r. Andi Kleen (ak@xxxxxx) "[PATCH] Some fixes for compat ioctl":
> 
> While doing some compat_ioctl conversions I noticed a few issues
> in compat_sys_ioctl:
> 
> - It is not completely compatible to old ->ioctl because 
> the traditional common ioctls are not checked before it.

How is this different from what we have for compat_sys_ioctl
in 2.6.10? Or is this an old bug?

> I added
> a check for those.

Cant we just add them to fs/compat_ioctl.c instead, and be done?

> The main advantage is that the handler 
> now works the same as a traditional handler even when it returns
> -EINVAL


We still need the conversion functions in fs/compat_ioctl.c, I
think. If that is true, for some devices the handler only almost works
if it returns -EINVAL, and maybe its best not to encourage this.
I have another idea: maybe, lets move the unlocked_ioctl handler up so
that it, too, is required to return -NOIOCTLCMD?
I would argue it also may improve ioctl performance by a small margin,
since it is the unlocked_ioctl/compat_ioctl that do the "real" work.

I plan to send, separately, a patch that does this.
Please comment.

> 
> - The private socket ioctl check should only apply for sockets.

Its an old issue, isnt it? And probably better split in a separate
patch?

> - There was a security hook missing.  Drawback is that it uses
> the same hook now, and the LSM module cannot distingush between
> 32bit and 64bit clients. But it'll have to live with that for now.

It seems it is still missing for compat_ioctl. No?
I am sending a patch to fix this separately.

MST
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/