linux-kernel - Re: [PATCH 1/4] platform/x86: think-lmi: Enable opcode support on BIOS settings

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: <edd69d45-4d84-4982-aa57-2b420ce0b374@app.fastmail.com>
Date:   Thu, 25 May 2023 09:54:35 -0400
From:   "Mark Pearson" <mpearson-lenovo@...ebb.ca>
To:     "Hans de Goede" <hdegoede@...hat.com>
Cc:     "markgross@...nel.org" <markgross@...nel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] platform/x86: think-lmi: Enable opcode support on BIOS
 settings

On Thu, May 25, 2023, at 5:52 AM, Hans de Goede wrote:
> Hi Mark,
>
> On 5/24/23 20:20, Mark Pearson wrote:
>> Hi Hans,
>> 
>> On Tue, May 23, 2023, at 8:36 AM, Mark Pearson wrote:
>>> Thanks Hans,
>>>
>>> On Tue, May 23, 2023, at 6:46 AM, Hans de Goede wrote:
>>>> Hi Mark,
>>>>
>>>> On 5/17/23 20:19, Mark Pearson wrote:
>>>>> Whilst reviewing some documentation from the FW team on using WMI on
>>>>> Lenovo system I noticed that we weren't using Opcode support when
>>>>> changing BIOS settings in the thinkLMI driver.
>>>>>
>>>>> We should be doing this to ensure we're future proof as the old
>>>>> non-opcode mechanism has been deprecated.
>>>>>
>>>>> Tested on X1 Carbon G10 and G11.
>>>>>
>>>>> Signed-off-by: Mark Pearson <mpearson-lenovo@...ebb.ca>
>>>>> ---
>>>>>  drivers/platform/x86/think-lmi.c | 23 ++++++++++++++++++++++-
>>>>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/platform/x86/think-lmi.c b/drivers/platform/x86/think-lmi.c
>>>>> index 1138f770149d..d9341305eba9 100644
>>>>> --- a/drivers/platform/x86/think-lmi.c
>>>>> +++ b/drivers/platform/x86/think-lmi.c
>>>>> @@ -1001,7 +1001,28 @@ static ssize_t current_value_store(struct kobject *kobj,
>>>>>  				tlmi_priv.pwd_admin->save_signature);
>>>>>  		if (ret)
>>>>>  			goto out;
>>>>
>>>>> -	} else { /* Non certiifcate based authentication */
>>>>> +	} else if (tlmi_priv.opcode_support) {
>>>>> +		/* If opcode support is present use that interface */
>>>>> +		set_str = kasprintf(GFP_KERNEL, "%s,%s;", setting->display_name,
>>>>> +					new_setting);
>>>>> +		if (!set_str) {
>>>>> +			ret = -ENOMEM;
>>>>> +			goto out;
>>>>> +		}
>>>>> +
>>>>> +		ret = tlmi_simple_call(LENOVO_SET_BIOS_SETTINGS_GUID, set_str);
>>>>> +		if (ret)
>>>>> +			goto out;
>>>>> +
>>>>> +		if (tlmi_priv.pwd_admin->valid && tlmi_priv.pwd_admin->password[0]) {
>>>>> +			ret = tlmi_opcode_setting("WmiOpcodePasswordAdmin",
>>>>> +					tlmi_priv.pwd_admin->password);
>>>>> +			if (ret)
>>>>> +				goto out;
>>>>> +		}
>>>>> +
>>>>> +		ret = tlmi_save_bios_settings("");
>>>>
>>>> I'm a bit confused about how this works. You are calling the same
>>>> LENOVO_SET_BIOS_SETTINGS_GUID as the old non opcode based authentication method
>>>> without any auth string.
>>>>
>>>> And then afterwards you are calling LENOVO_OPCODE_IF_GUID with
>>>> "WmiOpcodePasswordAdmin:<passwd>"
>>>>
>>>> Won't the initial LENOVO_SET_BIOS_SETTINGS_GUID get rejected since
>>>> it does not include an auth-string and you have not authenticated
>>>> yet using the opcode mechanism either. IOW shouldn't the opcode
>>>> auth call go first ?
>>>>
>>>> And how does this work timing wise, vs races with userspace doing
>>>> multiple sysfs writes at once.
>>>>
>>>> If the authentication done afterwards really acks the last
>>>> LENOVO_SET_BIOS_SETTINGS_GUID call then a userspace based
>>>> attacker could try to race and overwrite the last
>>>> LENOVO_SET_BIOS_SETTINGS_GUID call before the ack happens... ?
>>>>
>>>> If this code really is correct I think we need to introduce
>>>> a mutex to avoid this race.
>>>>
>>>> And this also needs some comments to explain what is going on.
>>>
>>> Agreed - and looking at it now....I'm questioning it myself. This was 
>>> tested so it works...but I wonder if that was more luck than judgement.
>>> Let me do some checking - I think I may have messed up here.
>>>
>> 
>> Looked at this and the code is correct - even if it is a bit weird :)
>> https://docs.lenovocdrt.com/#/bios/wmi/wmi_guide?id=set-and-save-a-bios-setting-on-newer-models
>> 
>> The save_bios_settings would fail if a password was not set (if it's required).
>
> Ok, can you add some comments to the next revision explaining this ?
> (no need to write a novel, just some short comments)

Of course - no problem :)

>
>> With regards to race conditions - that does seem somewhat unlikely in real life but I can add a mutex around this to catch that condition. I think I should probably do the same in a couple of other places (e.g. certificate_store and new_password_store) where multiple WMI calls are needed to complete an operation. 
>
> Ack for also adding the mutex in other places where there is more
> then 1 WMI call involved.
>
>> Is it OK if I do that as a separate commit on the end of the series or would you rather it was included in this commit? As the scope is, I think, more than just this function I'm leaning towards a separate commit but let me know what best practice is.
>
> Adding this in a separate commit is fine with me.

Thanks. I'll work on that and get a v2 series out shortly

Mark