Re: [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys

Re: [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys

[Sasha Finkelstein]

On Oct 29, 2026, at 09:52, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
> 
> Add a /dev/smc device so userspace can talk to the SMC
> directly. 

This should either be dropped from the series, or be hidden behind a
`melt_my_mac`-style module flag, or switched to a whitelist approach.
We do not know what keys will be introduced in new smc firmware
versions, and there are already keys that should not be randomly poked
at.

Re: [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys

[Atharva Tiwari]

> This should either be dropped from the series, or be hidden behind a
> `melt_my_mac`-style module flag, or switched to a whitelist approach.
> We do not know what keys will be introduced in new smc firmware
> versions, and there are already keys that should not be randomly poked
> at.

1. The patch is required, atleast on intel macs, as without writing GPU and CPU
	states to smc, the system gives PROCHOT signal under small load
	, and heats up a lot.

2. the smc dosent expose keys of nature that can physically damage the system
	it only exposes power/volt data, and the most you can poke is reboot
	keys and gpu/cpu p-states.

3. If a person is randomly touching keys, Its their problem and not ours.

4. There are a lot of things that can mess the system way more and permanently
	than smc (undervolting for example), but they are not safe guarded, why
	should this be then?

Re: [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys

[Sasha Finkelstein]

On Oct 29, 2026, at 15:39, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
> 1. The patch is required, atleast on intel macs, as without writing GPU and CPU
> states to smc, the system gives PROCHOT signal under small load
> , and heats up a lot.

In that case, why are you exposing a generic smc key interface instead
of one that just does that? If you think that this data should be set
from userspace - whitelist the set of keys that are needed.


> 2. the smc dosent expose keys of nature that can physically damage the system
> it only exposes power/volt data, and the most you can poke is reboot
> keys and gpu/cpu p-states.

Are you willing to make that claim for every smc-equipped device, not
just T2? Are you willing to make the same claim for future versions of
smc firmware?

> 3. If a person is randomly touching keys, Its their problem and not ours.
> 
> 4. There are a lot of things that can mess the system way more and permanently
> than smc (undervolting for example), but they are not safe guarded, why
> should this be then?

I think it is inadvisable to leave a loaded footgun around and then
blame the user for using it. As an "OS Vendor" you have a duty of care
to your users.

Re: [RFC PATCH 14/14] mfd/macsmc: add ioctl to access smc keys

[Aditya Garg]

On 10/29/26 8:23 PM, Sasha Finkelstein wrote:
> On Oct 29, 2026, at 15:39, Atharva Tiwari <atharvatiwarilinuxdev@gmail.com> wrote:
>> 1. The patch is required, atleast on intel macs, as without writing GPU and CPU
>> states to smc, the system gives PROCHOT signal under small load
>> , and heats up a lot.
> 
> In that case, why are you exposing a generic smc key interface instead
> of one that just does that? If you think that this data should be set
> from userspace - whitelist the set of keys that are needed.
> 

Whitelisting will create an endless cycle of upstreaming new keys. But 
considering T2 no longer is receiving updates, Asahi would be happy to 
send their keys they wish to be whitelisted right ;)>
>> 2. the smc dosent expose keys of nature that can physically damage the system
>> it only exposes power/volt data, and the most you can poke is reboot
>> keys and gpu/cpu p-states.
> 
> Are you willing to make that claim for every smc-equipped device, not
> just T2? Are you willing to make the same claim for future versions of
> smc firmware?

Fair enough. We can restrict it to T2 Macs, and Asahi can later adopt if 
useful?>
>> 3. If a person is randomly touching keys, Its their problem and not ours.
>>
>> 4. There are a lot of things that can mess the system way more and permanently
>> than smc (undervolting for example), but they are not safe guarded, why
>> should this be then?
> 
> I think it is inadvisable to leave a loaded footgun around and then
> blame the user for using it. As an "OS Vendor" you have a duty of care
> to your users.

It would say the "duty of care" argument is more of a philosophical 
thing than a technical argument here. Still, I respect that but there 
needs to be a balance between adding features and respecting the duty. 
It seems various vendors have different views in determining the 
balance. The above 2 arguments look like a good balance. What do you think?