On Thu, Feb 24, 2022 at 8:24 AM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > On Thu, Feb 24, 2022 at 08:17:52AM +0900, Levi Yun wrote: > > Suppose a module registers its own binfmt (custom) and formats is like: > > > > +---------+ +----------+ +---------+ > > | custom | -> | format1 | -> | format2 | > > +---------+ +----------+ +---------+ > > > > and try to call unregister_binfmt with custom NOT in __exit stage. > > Explain, please. Why would anyone do that? And how would such > module decide when it's safe to e.g. dismantle data structures > used by methods of that binfmt, etc.? > Could you give more detailed example? I think if someone wants to control their own binfmt via "ioctl" not on time on LOAD. For example, someone wants to control exec (notification, allow/disallow and etc..) and want to enable and disable own's control exec via binfmt reg / unreg In that situation, While the module is loaded, binfmt is still live and can be reused by reg/unreg to enable/disable his exec' control. module can decide it's safe to unload by tracing the stack and confirming whether some tasks in the custom binfmt's function after it unregisters its own binfmt. > Because it looks like papering over an inherently unsafe use of binfmt interfaces.. I think the above example it's quite a trick and stupid. it's quite unsafe to use as you mention. But, misuse allows that situation to happen without any warning. As a robustness, I just try to avoid above situation But, I think it's better to restrict unregister binfmt unregister only when there is no module usage.
