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-next>] [day] [month] [year] [list]
Message-ID: <CAGRSmLu8iHLC-vLRdXu3QYpOZspGbwKb0eRTFe_iA4KCxCx6nQ@mail.gmail.com>
Date:	Fri, 12 Feb 2016 23:45:38 -0800
From:	"David F." <df7729@...il.com>
To:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Allowing external modules to run across more configs and distros

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ