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] [day] [month] [year] [list]
Message-ID: <20180211225735.ql6gbi5oxpsnurkc@pali>
Date:   Sun, 11 Feb 2018 23:57:35 +0100
From:   Pali Rohár <pali.rohar@...il.com>
To:     Mario.Limonciello@...l.com
Cc:     platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
        dvhart@...radead.org, andy.shevchenko@...il.com
Subject: Re: Dell SMBIOS initializing before backends are ready

On Thursday 08 February 2018 18:23:23 Mario.Limonciello@...l.com wrote:
> After Paul's recent message regarding the odd wifi issue he had a 
> comment I wanted to investigate:
> 
> dell_smbios: "No dell-smbios drivers are loaded"
> 
> Coming up early in boot.  This is a side effect of dell-smbios having two
> backend drivers that can be compiled as modules but no tie to force
> them to initialize before calls to dell_smbios_call.
> 
> So I believe what is happening is dell_micmute_led_set is called from
> the HDA driver and calls dell_smbios_call early too.
> 
> I haven't tried it on a platform with mic mute, but I suspect it might cause
> the mic mute LED status to be wrong initially (but corrected later when 
> toggled).
> 
> Ideas that came to mind:
> 
> 1) In dell_smbios_call if no backends loaded, explicitly do a symbol_request
> for both backends and run initialization at that time.
> 
> If that works, that would also resolve if someone manually unloaded both
> backends but a kernel module still tried to perform a request.
> 
> 2) Add a notifier chain for when the driver is ready (a backend is loaded)
> to all consumers of dell_smbios_call.  Don't let other modules call
> dell_smbios_call until notified.
> Don't let the HDA driver call dell_micmute_led_set either.
> 
> 3) try_module_get during dell-smbios initialization for both the backends
> 
> What's the correct way to address this?

I'm not really sure what is the best approach.

But in my opinion, if somebody call blocking function symbol_request()
then after function return, caller wants to use this symbol and expects
to be ready. Therefore I think that exported function
(dell_micmute_led_set) should probably ensure that everything is
initialized and after that continue... So maybe add "initialize & wait
until backends are ready" code into beginning of that function?

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ