linux-kernel - Re: [PATCH v4 1/1] applesmc: Re-work SMC comms

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:   Wed, 11 Nov 2020 18:05:42 +1100
From:   Brad Campbell <brad@...rfbargle.com>
To:     Guenter Roeck <linux@...ck-us.net>, linux-hwmon@...r.kernel.org
Cc:     Arnd Bergmann <arnd@...db.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        hns@...delico.com, Andreas Kemnade <andreas@...nade.info>,
        Jean Delvare <jdelvare@...e.com>,
        Henrik Rydberg <rydberg@...math.org>
Subject: Re: [PATCH v4 1/1] applesmc: Re-work SMC comms

On 11/11/20 4:56 pm, Guenter Roeck wrote:
> On 11/10/20 7:38 PM, Brad Campbell wrote:
>> Commit fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> introduced an issue whereby communication with the SMC became
>> unreliable with write errors like :
>>
>> [  120.378614] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.378621] applesmc: LKSB: write data fail
>> [  120.512782] applesmc: send_byte(0x00, 0x0300) fail: 0x40
>> [  120.512787] applesmc: LKSB: write data fail
>>
>> The original code appeared to be timing sensitive and was not reliable
>> with the timing changes in the aforementioned commit.
>>
>> This patch re-factors the SMC communication to remove the timing
>> dependencies and restore function with the changes previously
>> committed.
>>
>> Tested on : MacbookAir6,2 MacBookPro11,1 iMac12,2, MacBookAir1,1,
>> MacBookAir3,1
>>
>> Fixes: fff2d0f701e6 ("hwmon: (applesmc) avoid overlong udelay()")
>> Reported-by: Andreas Kemnade <andreas@...nade.info>
>> Tested-by: Andreas Kemnade <andreas@...nade.info> # MacBookAir6,2
>> Acked-by: Arnd Bergmann <arnd@...db.de>
>> Signed-off-by: Brad Campbell <brad@...rfbargle.com>
>> Signed-off-by: Henrik Rydberg <rydberg@...math.org>
>>
>> ---
>> Changelog : 
>> v1 : Initial attempt
>> v2 : Address logic and coding style
>> v3 : Removed some debug hangover. Added tested-by. Modifications for MacBookAir1,1
>> v4 : Re-factored logic based on Apple driver. Simplified wait_status loop
>> Index: linux-stable/drivers/hwmon/applesmc.c
>> ===================================================================
>> --- linux-stable.orig/drivers/hwmon/applesmc.c
>> +++ linux-stable/drivers/hwmon/applesmc.c
>> @@ -32,6 +32,7 @@
>>  #include <linux/hwmon.h>
>>  #include <linux/workqueue.h>
>>  #include <linux/err.h>
>> +#include <linux/bits.h>
>>  
>>  /* data port used by Apple SMC */
>>  #define APPLESMC_DATA_PORT	0x300
>> @@ -42,10 +43,14 @@
>>  
>>  #define APPLESMC_MAX_DATA_LENGTH 32
>>  
>> -/* wait up to 128 ms for a status change. */
>> -#define APPLESMC_MIN_WAIT	0x0010
>> -#define APPLESMC_RETRY_WAIT	0x0100
>> -#define APPLESMC_MAX_WAIT	0x20000
>> +/* Apple SMC status bits */
>> +#define SMC_STATUS_AWAITING_DATA  BIT(0) /* SMC has data waiting to be read */
>> +#define SMC_STATUS_IB_CLOSED      BIT(1) /* Will ignore any input */
>> +#define SMC_STATUS_BUSY           BIT(2) /* Command in progress */
>> +
>> +/* Exponential delay boundaries */
>> +#define APPLESMC_MIN_WAIT	0x0008
>> +#define APPLESMC_MAX_WAIT	0x100000
> 
> This is a substantial increase in wait time which should be documented.
> 0x20000 was explained (it translated to 128 ms), but this isn't,
> and no reason is provided why it was increased to one second.
> Is there any evidence that this is needed ? The only "benefit" I
> can see is that a stuck SMC will now hang everything 8 times longer.
> 
> There really should be some evidence suggesting that the longer
> timeout is really needed, better than "the apple driver does it".
> The timeout was increased to 128 ms back in 2012, according to
> the commit because timeouts were observed on MacBookPro6,1.
> I would expect something similar here. In other words, describe
> the circumstances of observed timeouts and the affected system(s).
> 
G'day Guenter,

The wait timer turns out to be the most contentious part of the whole patch.

That particular algorithm was put forward off list, and in testing it was as
fast as {while true ; do stuff; udelay(10)}. The reason for the larger max value
isn't actually for timing purposes. It was to allow a minimum of 16 times around the hedge.

I've probably had 10 chops at this timeout trying to balance performance with a sane
algorithm. 

How does this look? This performs pretty well.

/* Minimum sleep time is 8uS */
#define APPLESMC_MIN_WAIT      0x0008

/*
 * Wait for specific status bits with a mask on the SMC.
 * Used before all transactions.
 * This does 10 fast loops of 8us then exponentially backs off for a 
 * minimum total wait of 262ms. Depending on usleep_range this could
 * run out past 500ms. 
 */

static int wait_status(u8 val, u8 mask)
{
	u8 status;
	int us;
	int i;
	
	us=APPLESMC_MIN_WAIT;
	for (i = 0; i < 24 ; i++) {
		status = inb(APPLESMC_CMD_PORT);
		if ((status & mask) == val)
			return 0;
		usleep_range(us, us * 2);
		if (i > 9)
			us <<= 1;
	}
	return -EIO;
}

Regards,
Brad