32bit userland cannot work with DVB drivers in 64bit kernel, design issue

32bit userland cannot work with DVB drivers in 64bit kernel, design issue

[Menion]

Hi all
I am investigating for Armbian, the feasability of running 32bit
userland on single board computers based on arm64 SoC, where only 64
bit kernel is available, for reducing the memory footprint.
I have discovered that there is a flaw in the DVB frontend ioctl (at
least) that prevents to do so.
in frontend.h the biggest problem is:

struct dtv_properties {
__u32 num;
struct dtv_property *props;
};

The master userland-kernel ioctl structure is based on an array set by
pointer, so the 32bit userland will allocate 32bit pointer (and the
resulting structure size) while the 64bit kernel will expect the 64bit
pointers
Also

struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct dtv_fe_stats st;
struct {
__u8 data[32];
__u32 len;
__u32 reserved1[3];
void *reserved2;
} buffer;
} u;
int result;
} __attribute__ ((packed));

The void *reserved2 field will also give problem when crossing the
32-64bits boundaries
As today the endire dvb linux infrastructure can only work in 32-32
and 64-64 bit mode
Bye

Antonio

Re: 32bit userland cannot work with DVB drivers in 64bit kernel, design issue

[Alan Cox]

On Thu, 2 Nov 2017 12:16:39 +0100
Menion <menion@gmail.com> wrote:

> Hi all
> I am investigating for Armbian, the feasability of running 32bit
> userland on single board computers based on arm64 SoC, where only 64
> bit kernel is available, for reducing the memory footprint.
> I have discovered that there is a flaw in the DVB frontend ioctl (at
> least) that prevents to do so.
> in frontend.h the biggest problem is:
> 
> struct dtv_properties {
> __u32 num;
> struct dtv_property *props;
> };
> 
> The master userland-kernel ioctl structure is based on an array set by
> pointer, so the 32bit userland will allocate 32bit pointer (and the
> resulting structure size) while the 64bit kernel will expect the 64bit
> pointers

And in some cases the pointer might end up aligned to the next 64bit
boundary.

> The void *reserved2 field will also give problem when crossing the
> 32-64bits boundaries
> As today the endire dvb linux infrastructure can only work in 32-32
> and 64-64 bit mode

If this isn't handled by the existing media compat_ioctl support then you
can send patches to use compat_ioctl handlers to fix this.

Alan

Re: 32bit userland cannot work with DVB drivers in 64bit kernel, design issue

[Menion]

For the moment, I am focusing on the frontend ioctl problem
According to the fops:

static const struct file_operations dvb_frontend_fops = {
.owner = THIS_MODULE,
.unlocked_ioctl = dvb_generic_ioctl,
.poll = dvb_frontend_poll,
.open = dvb_frontend_open,
.release = dvb_frontend_release,
.llseek = noop_llseek,
};

There is no support for compact_ioctl, so it must be added

2017-11-02 19:52 GMT+01:00 Alan Cox <gnomes@lxorguk.ukuu.org.uk>:
> On Thu, 2 Nov 2017 12:16:39 +0100
> Menion <menion@gmail.com> wrote:
>
>> Hi all
>> I am investigating for Armbian, the feasability of running 32bit
>> userland on single board computers based on arm64 SoC, where only 64
>> bit kernel is available, for reducing the memory footprint.
>> I have discovered that there is a flaw in the DVB frontend ioctl (at
>> least) that prevents to do so.
>> in frontend.h the biggest problem is:
>>
>> struct dtv_properties {
>> __u32 num;
>> struct dtv_property *props;
>> };
>>
>> The master userland-kernel ioctl structure is based on an array set by
>> pointer, so the 32bit userland will allocate 32bit pointer (and the
>> resulting structure size) while the 64bit kernel will expect the 64bit
>> pointers
>
> And in some cases the pointer might end up aligned to the next 64bit
> boundary.
>
>> The void *reserved2 field will also give problem when crossing the
>> 32-64bits boundaries
>> As today the endire dvb linux infrastructure can only work in 32-32
>> and 64-64 bit mode
>
> If this isn't handled by the existing media compat_ioctl support then you
> can send patches to use compat_ioctl handlers to fix this.
>
> Alan