linux-kernel - Re: Allowing external modules to run across more configs and distros

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 13 Feb 2016 00:13:09 -0800
From:	"David F." <df7729@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Allowing external modules to run across more configs and distros

After sending the below, I realized that if someone doesn't want to
have to dereference a pointer it could still be done the same way and
just omitting the member variable (options).  You would just always
allocate (sizeof (struct module)+sizeof(struct modconfigopts)) and to
access the options, use a different macro: #define MOD_OPT(m) ((struct
modconfigopts*)((m)+1))  --or-- #define MOD_OPT(m) ((struct
modconfigopts*)((int8_t*)(m)+sizeof(*m)))
example of when an optional item is reference:
MOD_OPT(THIS_MODULE)->param_lock

now you don't have any dereferencing of the pointer.


On Fri, Feb 12, 2016 at 11:45 PM, David F. <df7729@...il.com> wrote:
> While creating a linux module that should be usable across a wide
> array of linux versions and builds, I've run into struct modules
> (THIS_MODULE) being a problem.  It's the only internal struct accessed
> as a requirement to struct block_device_operations .owner.   It's a
> bit annoying for this module to be rejected for nothing it has any
> interest in using.  So I was thinking of a quick solution but don't
> want to waste my time if people will resist it (not sure when I'll
> have time to do it, but should be able to do it quickly once i'd have
> all the source local).  The idea is:
>
> Take all #if defines out of the struct module and place them in a
> separate struct (struct modconfigopts).  Place a single member
> variable at the end of struct modules as void * (void *options) to
> access the options.  Have a single macro to access the options member
> variable for the internal code that access it (#define MOD_OPT(v)
> ((struct modconfigopts*)(v)).  So internal code would use
> module->MOD_OPT(options)->param_lock for example.
>
> When the module structure is created, it would initialize the options
> member variable (the memory allocated (sizeof(struct
> module)+sizeof(struct modconfigopts)) could be contiguous so it's like
> one big structure, then cleanup would be the same).
>
> Doing this should then allow "external" modules that don't need access
> to the "internal" config options to continue to load and work across a
> much greater range of Linux distributions.
>
> What do you think?