[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fa9c73f385a649cfbedae47f21a5447f@AcuMS.aculab.com>
Date: Tue, 2 Apr 2019 10:26:30 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Borislav Petkov' <bp@...en8.de>, Jann Horn <jannh@...gle.com>
CC: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
the arch/x86 maintainers <x86@...nel.org>,
kernel list <linux-kernel@...r.kernel.org>,
Qiaowei Ren <qiaowei.ren@...el.com>,
Mukesh Ojha <mojha@...eaurora.org>
Subject: RE: [PATCH v3 2/4] x86/microcode: Fix __user annotations around
generic_load_microcode()
From: Borislav Petkov
> Sent: 02 April 2019 11:02
>
> On Mon, Apr 01, 2019 at 07:53:46PM +0200, Jann Horn wrote:
> > Hm. request_microcode_fw() gets that buffer from
> > request_firmware_direct(), which does this:
> >
> > __module_get(THIS_MODULE);
> > ret = _request_firmware(firmware_p, name, device, NULL, 0,
> > FW_OPT_UEVENT | FW_OPT_NO_WARN |
> > FW_OPT_NOFALLBACK);
> > module_put(THIS_MODULE);
> > return ret;
> >
> > What is that module_get()/module_put() supposed to be good for? Are we
> > expecting that caller to do something ridiculous like calling
> > module_put() on us? This doesn't seem to make any sense.
>
> Yah, the microcode thing used to be a module. Not anymore.
That probably makes diddly-squit difference.
There has to be a 'hold' on THIS_MODULE in order to be executing
code from it.
You only (usually) need an extra reference for a kernel thread,
and that needs to exit with module_put_and_exit().
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists