2 ms·

I see a lot of concerns here that the LEDs are software controlled. Judging from the source code of the privacy driver [0], it doesn't look like it. I'm not to

by LeonM 6y ago

I see a lot of concerns here that the LEDs are software controlled. Judging from the source code of the privacy driver [0], it doesn't look like it. I'm not too familiar with the kernel interface for LEDs, but as far as I can understand stubs are added to read back the LED status, but not so much setting it. Phoronix's description of 'manipulating the relevant LEDs' seems to be misleading. [0] https://lore.kernel.org/lkml/20201103125542.8572-1-Perry_Yuan@Dell.com/ https://lore.kernel.org/lkml/20201103125542.8572-1-Perry_Yua...

slezyr 6y ago
It looks like `micmute_led_set` does exactly this.
- LeonM 6y ago
  I don't think it does. It doesn't look like the method is actually using the 'brightness' argument. It's just reading the ACPI status bits to update the current state. It doesn't set anything. static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { acpi_status status; status = acpi_evaluate_object(NULL, ACPI_PRIVACY_EC_ACK, NULL, NULL); if (ACPI_FAILURE(status)) { dev_err(led_cdev->dev, "Error setting privacy audio EC ack value: %d\n",status); return -EIO; } return 0; }
  - slezyr 6y ago
    I've assumed that there is a kernel voodoo magic happens, but it seems that the reviewer is also confused by this. https://lore.kernel.org/lkml/20201104014915.45tbmnrqvccbrd2k@srcf.ucam.org/#t https://lore.kernel.org/lkml/20201104014915.45tbmnrqvccbrd2k... Might be copy/paste from another driver or they will implement it later.
adrianmonk 6y ago
If I'm reading it right, another LKML message seems to confirm that the muting LED is hardware controlled. From https://lkml.org/lkml/2020/11/3/904 https://lkml.org/lkml/2020/11/3/904: > I don't think it came through in the commit message, but I wanted to mention in the system that prompted this software does not control the LED. The LED is actually controlled by hardware, but has circuitry to delay the hardware mute until software mute is complete to avoid any "popping noises". That's followed by someone asking about a timeout in case software mute never happens (so that hardware mute still does), and the same person confirms there is a timeout.
- labawi 6y ago
  Without further details, I remain unconvinced of true hardware security. By hardware I would presume they mean a system/keyboard controller - one that can monitor events, delay and toggle privacy mode. A controller that likely has updateable firmware and could be compromised via SW given sufficient effort (TLA, Dell, &c). The privacy mode might be unsubvertible via SW, but I wouldn't take their word for it.

by LeonM 6y ago

slezyr 6y ago

It looks like `micmute_led_set` does exactly this.

LeonM 6y ago
I don't think it does. It doesn't look like the method is actually using the 'brightness' argument. It's just reading the ACPI status bits to update the current state. It doesn't set anything. static int micmute_led_set(struct led_classdev *led_cdev, enum led_brightness brightness) { acpi_status status; status = acpi_evaluate_object(NULL, ACPI_PRIVACY_EC_ACK, NULL, NULL); if (ACPI_FAILURE(status)) { dev_err(led_cdev->dev, "Error setting privacy audio EC ack value: %d\n",status); return -EIO; } return 0; }
- slezyr 6y ago
  I've assumed that there is a kernel voodoo magic happens, but it seems that the reviewer is also confused by this. https://lore.kernel.org/lkml/20201104014915.45tbmnrqvccbrd2k@srcf.ucam.org/#t https://lore.kernel.org/lkml/20201104014915.45tbmnrqvccbrd2k... Might be copy/paste from another driver or they will implement it later.

adrianmonk 6y ago

If I'm reading it right, another LKML message seems to confirm that the muting LED is hardware controlled. From https://lkml.org/lkml/2020/11/3/904 https://lkml.org/lkml/2020/11/3/904: > I don't think it came through in the commit message, but I wanted to mention in the system that prompted this software does not control the LED. The LED is actually controlled by hardware, but has circuitry to delay the hardware mute until software mute is complete to avoid any "popping noises". That's followed by someone asking about a timeout in case software mute never happens (so that hardware mute still does), and the same person confirms there is a timeout.

labawi 6y ago
Without further details, I remain unconvinced of true hardware security. By hardware I would presume they mean a system/keyboard controller - one that can monitor events, delay and toggle privacy mode. A controller that likely has updateable firmware and could be compromised via SW given sufficient effort (TLA, Dell, &c). The privacy mode might be unsubvertible via SW, but I wouldn't take their word for it.