linux-kernel - Re: [PATCH v2] applesmc: add sysfs file to report OSK

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, 12 Dec 2012 18:01:28 -0500
From:	"Gabriel L. Somlo" <somlo@....edu>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Guenter Roeck <groeck-dsl@...global.net>, khali@...ux-fr.org,
	linux@...ck-us.net, lm-sensors@...sensors.org,
	linux-kernel@...r.kernel.org, agraf@...e.de, rene@...ctcode.com
Subject: Re: [PATCH v2] applesmc: add sysfs file to report OSK

Henrik, I agree with you that it's silly to poke the hardware for a
string we KNOW will NEVER change :)

That being said, I too would love to live in a world where technical
common sense prevailed over bullshit lawyerly tactics, "corporate
strategies", and the ensuing FUD.

The way things stand today, in order to boot Mac OS X on QEMU/KVM/Linux
(running on Mac hardware of course, in compliance with Apple's license)
requires the end user supplying the OSK on the QEMU command line via the
-osk="..." argument.

I would like to make it easy for people who run Linux natively on Apple
hardware (of which I am one) to run OS X from QEMU "out of the box".

I could try to hardcode the OSK inside QEMU, or I could try to include
it as a default config file entry, but I'm quite certain the QEMU project
would be uncomfortable "distributing" a string on which Apple claims
copyright. Even if that happened, distros might then balk at shipping
QEMU as part of their package repositories, for the exact same reason.

Currently, we're all beating around the bush about the OSK, with vague
hints and hoops to jump through for end users to acquire the OSK and
pass it to QEMU on the command line. This process will have the
unfortunate side effect of filtering out "normal" users :(

The only viable (from a legal CYA standpoint) thing I can think of is
to make it easy to acquire the OSK automatically, on demand, directly
from the hardware. Right now, the logical place for that is applesmc.ko.
It already controls access to the SMC, and already reports values for
various keys.

Yes it may feel silly to "go through the motions" when you KNOW it's
always going to be the same value that gets returned. But this patch
is mostly about reassuring people that lawyers will continue not to
have a reason to get involved...

Thanks for reading, and hope I'm being sufficiently persuasive :)
--Gabriel

>  drivers/hwmon/applesmc.c |   19 +++++++++++++++++++
>  1 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index b41baff..b37b271 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -1013,6 +1013,24 @@ static ssize_t applesmc_key_at_index_store(struct device *dev,
>  	return count;
>  }
>  
> +static ssize_t applesmc_osk_show(struct device *dev,
> +				struct device_attribute *attr, char *sysfsbuf)
> +{
> +	int ret;
> +	char buf[65];
> +
> +	mutex_lock(&smcreg.mutex);
> +	ret = read_smc(APPLESMC_READ_CMD, "OSK0", buf, 32);
> +	if (!ret)
> +		ret = read_smc(APPLESMC_READ_CMD, "OSK1", buf + 32, 32);
> +	mutex_unlock(&smcreg.mutex);
> +	if (ret)
> +		return ret;
> +
> +	buf[64] = '\0';
> +	return snprintf(sysfsbuf, PAGE_SIZE, "%s\n", buf);
> +}
> +
>  static struct led_classdev applesmc_backlight = {
>  	.name			= "smc::kbd_backlight",
>  	.default_trigger	= "nand-disk",
> @@ -1027,6 +1045,7 @@ static struct applesmc_node_group info_group[] = {
>  	{ "key_at_index_type", applesmc_key_at_index_type_show },
>  	{ "key_at_index_data_length", applesmc_key_at_index_data_length_show },
>  	{ "key_at_index_data", applesmc_key_at_index_read_show },
> +	{ "osk", applesmc_osk_show },
>  	{ }
>  };
>  
> -- 
> 1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/