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
| ||
|
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?
Powered by blists - more mailing lists