linux-kernel - Re: [PATCH 09/17] firmware: qcom_scm-64: Improve SMC convention detection

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 07 Nov 2019 12:20:44 -0800
From:   eberman@...eaurora.org
To:     Bjorn Andersson <bjorn.andersson@...aro.org>
Cc:     saiprakash.ranjan@...eaurora.org, agross@...nel.org,
        tsoni@...eaurora.org, sidgup@...eaurora.org,
        psodagud@...eaurora.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/17] firmware: qcom_scm-64: Improve SMC convention
 detection

On 2019-11-07 11:18, Bjorn Andersson wrote:
>> +		(qcom_smc_convention == SMC_CONVENTION_ARM_64) ?
>> +			ARM_SMCCC_SMC_64 :
>> +			ARM_SMCCC_SMC_32,
> 
> Here SMC_CONVENTION_UNKNOWN would mean ARM_SMCCC_SMC_32...

Idea is that __qcom_scm_call_smccc would only be called if 
qcom_smc_convention
is SMC_CONVENTION_ARM_64 or _32. It should not be possible to get into
__qcom_scm_call_smccc with the current convention being 
SMC_CONVENTION_UNKNOWN.

> 
>>  		desc->owner,
>>  		SMCCC_FUNCNUM(desc->svc, desc->cmd));
>>  	smc.a[1] = desc->arginfo;
>> @@ -117,7 +125,7 @@ static int ___qcom_scm_call_smccc(struct device 
>> *dev,
>>  		if (!args_virt)
>>  			return -ENOMEM;
>> 
>> -		if (qcom_smccc_convention == ARM_SMCCC_SMC_32) {
>> +		if (qcom_smc_convention == SMC_CONVENTION_ARM_32) {
> 
> ...but here it would mean ARM_SMCCC_SMC_64.

I will clean up to be consistent what the "else" case is.


>> @@ -583,19 +591,17 @@ int __qcom_scm_qsmmu500_wait_safe_toggle(struct 
>> device *dev, bool en)
>> 
>>  void __qcom_scm_init(void)
>>  {
>> -	u64 cmd;
>> -	struct arm_smccc_res res;
>> -	u32 function = SMCCC_FUNCNUM(QCOM_SCM_SVC_INFO, 
>> QCOM_SCM_INFO_IS_CALL_AVAIL);
>> -
>> -	/* First try a SMC64 call */
>> -	cmd = ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64,
>> -				 ARM_SMCCC_OWNER_SIP, function);
>> -
>> -	arm_smccc_smc(cmd, QCOM_SCM_ARGS(1), cmd & 
>> (~BIT(ARM_SMCCC_TYPE_SHIFT)),
>> -		      0, 0, 0, 0, 0, &res);
>> -
>> -	if (!res.a0 && res.a1)
>> -		qcom_smccc_convention = ARM_SMCCC_SMC_64;
>> -	else
>> -		qcom_smccc_convention = ARM_SMCCC_SMC_32;
>> +	qcom_smc_convention = SMC_CONVENTION_ARM_64;
>> +	if (__qcom_scm_is_call_available(NULL, QCOM_SCM_SVC_INFO,
>> +			QCOM_SCM_INFO_IS_CALL_AVAIL) == 1)
>> +		goto out;
>> +
>> +	qcom_smc_convention = SMC_CONVENTION_ARM_32;
>> +	if (__qcom_scm_is_call_available(NULL, QCOM_SCM_SVC_INFO,
>> +			QCOM_SCM_INFO_IS_CALL_AVAIL) == 1)
>> +		goto out;
>> +
>> +	qcom_smc_convention = SMC_CONVENTION_UNKNOWN;
> 
> If above two tests can be considered reliable I would suggest that you
> fail hard here instead.

Is the suggestion here to BUG out?

Thanks,

Elliot


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum,
a Linux Foundation Collaborative Project