Dell Adding Hardware Privacy Driver for Linux | Hacker News Reader

Dell Adding Hardware Privacy Driver for Linux

phoronix.com

207 pointsreddotX88 comments

"These new Dell privacy buttons are basically hardware kill switches for the microphone and web camera video stream. The Dell privacy driver sent out on Tuesday for the Linux kernel is about manipulating the relevant LEDs and tracking the status of the hardware-based controls where as the actual toggling of the audio/video support is handled by the hardware."

Why not just wire the LEDs up to the same power line that goes to the camera?

That seems to be an issue with most webcams - the indicator light itself can be compromised and disabled.

I remember having a usb Logitech webcam that included disabling the indicator as a first class option in their control panel - not a big leap to imagine malware doing it

Third party webcams, yes.

Basically any modern laptop with a build-in webcam has a hardware controlled LED, not software controlled.

I don't see that this is necessarily true or easy to figure out.

They may be wired to the power line. I think the goal is more to give the kernel some way to know the mic/camera is explicitly disabled and not disconnected/missing/broken.

Wouldn't that tell any spy device / software that the subject has switched off the means he or she can be surveiled by? I cannot see how this could help with anything. They should rather do a physical switch that would 0 the data lines from these devices, so that camera or the microphone would be seen as working, but not sending any signal. Even better if you could pre-program some kind of ambience sound and pre-recorded cam video, so that once you turn it off, the perpetrator will think that they are still getting something.

It might be for usability reasons: having your video conferencing application tell you "Your webcam appears to be disabled by the privacy switch, is that intentional?" probably saves a lot of time in tech support calls.

Also, having your video conferencing application send some prerecorded audio and video data to your colleagues because you inadvertently turned the kill switch would not be a highly desirable outcome.

Why would you care about fooling surveillance? The goal is to prevent a potential adversary from getting any video/audio footage, them being aware of you actively blocking any attempts is not really relevant.

Besides, the vast majority of users will not be under active attack. Having an on-screen popup when you try to use the webcam telling you that it has been hardware-disabled is quite a must-have. If you don't have something like this, you'll get a lot of support calls which boil down to "you accidentally pressed the kill switch, press it again to re-enable".

> Why would you care about fooling surveillance?

For example, when you are "required" [1] to run surveillance software on your computer.

[1] https://www.vice.com/en/article/n7wxvd/students-are-rebellin...

...then you just cover the camera and/or mic with a physical cover, such a piece of tape.

> and/or mic

How well would tape work on that?

These exam proctoring softwares are only required to be run during the time you are actively taking an exam. The rest of the time, there would be zero issue for a student with hardware disabled camera and microphone.

The invasive proprietary software used to prevent cheating cannot be trusted to work only when the students want it work. Its purpose can and will be twisted to fit the agendas of whoever owns the software. It probably introduces several security vulnerabilities into the system just by being installed.

It's a Chrome extension.

> If you don't have something like this, you'll get a lot of support calls which boil down to "you accidentally pressed the kill switch, press it again to re-enable".

Yep. This was an extremely common issue in the mid-2000s, when laptops started integrating wireless hardware with hard power switches, often on the side of the laptop where they could easily be toggled by accident.

But was it a "fault" of the switch itself or lack of meaningful feedback that the switch was engaged? It seems like they have not implemented it properly and then say it wasn't a good idea, without really giving it a chance.

>They should rather do a physical switch that would 0 the data lines from these devices,

What exactly do you expect that to accomplish. Anyone actively targeting you getting literally NO SOUND OR VIDEO is going to know that you've flipped the switch just the same.

Even the quietest apartment has HVAC that will be picked up. If they're recording for hours they're going to hear people walking by. The camera itself will still provide an image, even if it's black, that looks different than no signal at all.

That's why the idea of having some pre-recorded stuff on tap, but sending no signal could waste some of the perpetrators resources, which I think is something nicer to have than letting them know it is switched off.

Sorry but if you're going to those lengths you should be buying a laptop without a camera or mic. Do video calls from your phone and put it in a soundproof/wireless transmission proof box.

If a nation state is able to get to your laptop they're going to figure out pretty quickly that you're "feeding something pre-recorded" into the mic and camera every time you have a meeting. Ignoring the insane effort you'd have to put out to feed that in and make it even semi-believable. For starters they are presumably tracking who you're meeting with - are you going to have a meeting before your meeting to pre-record? Hope they don't figure out that you're saying the exact same thing in two different meetings? Somehow have root on your laptop but aren't bright enough to figure out you're feeding data from a local file into your mic and camera?

Thank you! Great answer

I belive you can blacklist that driver if needed.

I believe the switches are there for the user as a simple way of activating or deactivating the microphone and camera and for them to know (via LEDs) the current state.

If you have a spy device connected to your computer or have malware running, you are very screwed in a million different ways already. Limiting knowledge of hardware state to malware doesn't buy you much.

>Wouldn't that tell any spy device / software that the subject has switched off the means he or she can be surveiled by?

And the spy device/software knowing the user has "switched off the means" vs "they are broken" is important because?

Unless you record infinite video and sound it's pretty easy to check if the video is a loop. Even static video of an empty room would have variations over time while a recording would be identical. Even auto-generated audio and noise would have a pattern which can be matched on. And if an attacker has control over your machine they can trivially correlate it with other activity to detect fake input.

It's basically a false sense of security which is generally worse than doing nothing.

If you can pattern match all auto generated audio you can prove there’s no one way functions and that cryptographic hash functions don’t exist.

Detecting the pattern in a prng stream is equivalent to finding its Kolmogorov complexity. https://en.m.wikipedia.org/wiki/Kolmogorov_complexity#Chaiti...

You're not pattern matching all auto-generated audio. You are pattern matching the audio generated by a specific algorithm. An attacker who has access to your microphone will know which laptop you have and what hardware it has.

This assumes an attacker is targeting you specifically since otherwise this is all moot (a broad attack could care less as to why your microphone is off).

You wouldn't be using a PRNG for this, because what would be the point? The idea would be to generate some plausible-sounding audio, not garbage that a listener would obviously know isn't real.

Really, though, in general there's just no point to this altogether; just cutting power/data to the mic is fine. There's no need to attempt to fool someone with fake audio, outside of some very edge-case scenarios that I'm sure Dell (rightly) does not care about.

If it is switched off, then you cannot be surveiled by it. Mission accomplished.

> Why not just wire the LEDs up to the same power line that goes to the camera?

It's just difficult enough to not bother considering the market doesn't care.

Webcams are typically USB 2.0 devices using generic drivers from the operating system or manufacturer. It's easy from a hardware and software perspective to send a command to the webcam to disable itself and turn off its LED. If you want to completely cut power then you need to add power switching circuitry.

You could use one of your CPU's limited GPIO pins to control the switching but now you probably need a smart power switch (~$0.30, which is significant) since the low voltage (1.2V?) GPIO can't handle switching a regular mosfet gate. GPIO writes are usually easy (just write to a memory address), but you'd still need to modify the vendor driver to do this and then distribute the driver.

Motherboards typically have embedded controllers which have GPIO - on desktops there is a SuperIO chip, I believe laptops typically use a regular microcontroller. Now you have some 3.3V GPIOs that can handle gate switching so you can use a regular MOSFET (~$0.10). You still need to modify and distribute the webcam driver, and now it might have to communicate with another driver which is handling the embedded controller.

Now you have to deal with the webcam disconnecting and reconnecting as you switch power to it. You want the device to always be present even if it's not enumerating on the USB bus, so you can select the webcam in zoom and turn it on and so you're not constantly playing the hardware connect/disconnect sound - even more driver changes. Maybe the webcam takes significantly longer to turn on now because it has to boot and enumerate.

That was all somewhat informed speculation, but I think it illustrates how a seemingly simple thing gets complicated. The electronics industry could easily solve these issues if there was motivation, but there just isn't.

Edit: Well, I'm posting this on an article talking about a vendor which is doing the work to make this happen. I guess I should say there's just enough motivation to eventually get around to solving this problem in a mature market.

Or you can just bake the functionality into the webcam itself (like apple) and a cheap commodity item becomes complicated and expensive.

You'll need a special firmware for the cam (like apple device), need to ensure integrity of the said firmware and also need a customized driver which needs maintenance work.

I have an old Logitech Pro 9000 camera with a lot of bells and whistles but, when I found out that its light can be managed by the driver and the UVC client in Linux AND it can turned off while it's recording, I've never kept it connected longer than it should be.

So yes, custom and secure hardware is hard.

False.

The market does care.

People want: hardware kill switches.

They want to cut their camera. (I've seen tape many times)

They want to mute their microphone for real.

Even non-nefarious "on-screen" mute buttons are subject to abuse.

For instance, in webex the conference host can unmute one or all of other people's mute buttons remotely. (To be clear there is a use case for this)

I wonder how many apps are listening even while mute is on. I would expect many of them.

and then there are exploits, which are lower probability but can do much more damage.

Connect the LED via current mirror to webcam power line? You will know when webcam is recording because it draws far more power.

A “kill switch” is more preferable because it prevents an attack, whereas wiring the LED to the power line only notifies you when you’ve been attacked; by then it’s too late; you’ve already been compromised.

Perhaps because all it takes is 1/24th of a second to make a picture?

Or because once the light is on, it's too late?

Or because I don't want to risk missing the light being on, just because the computer is on but I m not behind it?

So the NSA/CIA/FBI can enable the camera/mic without you knowing.

I remember a hack were basically if you just light up the camera, take a pic, and power off it, the led don't have enough time to emit light.

Even if the LED remained on, the victim would be powerless to do anything about the picture that was taken. I've seen videos on youtube of scammers doing this to blackmail their victims.

Kill switches should be mechanical and should physically disconnect the device from the system. Kill switches and lights that are controllable by software will be exploited.

I know, was just showing that LED wired on power is not enough.

It would be super nice for manufacturers to start doing that, but this is not a silver bullet. There's been so many times where I've just had my laptop stay open and on for different reasons. If in such scenarios the webcam comes on, the likelihood of me seeing the camera light on is quite low. I'm sure I'm not the only person either. Hardware switch is still the best solution.

My lenovo laptop has basically a builtin webcam cover, and I absolutely love it.

...Another LED for the data wire then?

What would that achieve exactly?

This one wouldn't be always on, but blink on signal. Way to differentiate between activity and just being plugged in.

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_Yua...

It looks like `micmute_led_set` does exactly this.

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;
  }

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...

Might be copy/paste from another driver or they will implement it later.

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:

> 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.

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.

The #1 feature of Dell laptops is the repair manual which allows you to, among other things, physically remove the camera and microphone without damaging the hardware.

Would be nice if they would release signed, flashable firmware images for remediating compromise.

This is fascinating to know.

I also have a dell monitor - I downloaded all the pdf manuals including one that said:

  "Statement of Volatility – Dell U3219Q Monitor

  The purpose of this document is to certify that the Dell
  U3219Q monitor will not save, retain, or reproduce a signal
  to any internal or external component after power has been
  removed and reapplied to the unit.

  The Dell U3219Q monitor contains both volatile and
  non-volatile (NV) memory ICs. Volatile memory(s) lose their
  data immediately upon removal of power. Non-volatile memory
  ICs continue to retain their data even after the power has
  been removed. However, no input video data is written into
  these memory ICs during operation.

  List below contains volatile and non volatile memory ICs
  used in the Dell U3219Q monitor."

Then it had a table for each storage chip within the monitor with its purpose and characteristics including:

  - system eeprom
  - hdmi edid eeprom
  - system flash rom 
  - usb hub eeprom
  - pd controller flash rom

These sort of documents are usually necessary when bringing in devices with memory in them into secure areas. Security likes to know what is in a device and if there is any special procedure that needs to happen to wipe any non-volatile memory. If there's no way to zero out or replace any memory that may have stored sensitive data, the device cannot leave the area.

I believe that having no camera and no microphone is necessary for some controlled security environments (especially government). Dell is big enough to consider that use-case?

PS: very happy with Dell’s Linux support for XPS laptops (still getting Linux specific Bios updates long after purchase).

Not necessarily directly related to this article, but with Linux adoption among OEMs exploding recently, doesn't this just continue to grow the size of the kernel? What keeps it from becoming an even bigger monolithic behemoth than it is now? Trimming out old/unmaintained drivers?

This is just something that's never crossed my mind until glancing at this article and thinking back to Microsoft adding all of their Hyper-V/DX12 stuff.

Drivers are typically built as modules in Linux. Under a running kernel, they don't exist in RAM unless loaded. They aren't typically loaded except by a hardware detection process or manually.

When I first played around compiling the linux kernel, I found that most of it is like a suburban garage, with a kayak and a brake bleeder and a hoe and golf clubs.

Except the kernel puts the suburban garage to shame.

My kernel config shows:

  CONFIG_HAMRADIO=y
  CONFIG_BAYCOM_SER_FDX=m  (from AX.25 network device drivers)
  CONFIG_CAN_SJA1000=m  (from CAN device drivers)
  CONFIG_NFC_MRVL=m    (from Near Field Communication (NFC) devices)

after a while I just scroll faster and faster zooming past:

  CONFIG_VMWARE_BALLOON=m
  CONFIG_HABANA_AI=m
  CONFIG_MACINTOSH_DRIVERS=y
  CONFIG_HAPPYMEAL=m

...and loadable module support for 4 heart rate monitors, 18 inertial measurement units and 18 magnetometer sensors. Even 2 VME bridge drivers.

There are 11,018 lines of this.

=y means it's compiled into the kernel

=m means it's a loadable module (but still takes up some kernel memory and more on disk as a .ko)

> =m means it's a loadable module (but still takes up some kernel memory and more on disk as a .ko)

Loadable modules are not present in memory, in any form, until they are loaded. Building them has no impact on kernel memory usage.

(Consider that it's possible to build the kernel with all the modules set to "n", then switch the modules to "m" and build them afterwards. The resulting kernel is identical, save for having a slightly different embedded .config.)

I'm sorry, I stand corrected, thanks for clarifying.

For some reason I thought there was a stub but maybe modprobe is smart and keeps things tidy.

There's a lot of stuff.

And the reason is that distributions usually build in support for a large amount of diverse hardware. These are modules (=m) where possible.

The motivation for this is: when you have that heart rate monitor, intertial measurement unit, magnetometer or something else, you just plug it in, the module gets loaded and the device just works.

Some things have to be =y and are unable to support =m.

To tidy up the garage, build a custom kernel and be loose with the use of =n.

True, but you would be surprised how little space each driver and feature take. The old and obscure ones are particularly tiny and efficiently implemented by modern standards.

For the latest 5.4.z kernel release, the full source tarball, xz-compressed, is 105 MB.

The fairly full-featured ubuntu build is smaller:

    Package: linux-image-5.4.0-52-generic
    Installed-Size: 11.7 MB
    Download-Size: 8887 kB

    Package: linux-modules-5.4.0-52-generic
    Installed-Size: 73.3 MB
    Download-Size: 14.5 MB

Now compare to, say, the smallest Windows container image you can find, or AMD or NVidia graphics driver installers ...

I thought CONFIG_HAPPYMEAL was a joke until I googled it :) This answers my question, thank you!

The privacy screen that can limit the viewable angle on demand is pretty cool. I hadn't heard about those before, but it is now definitely something I'll be looking for in my next laptop.

This is nice, but I'd rather just have a physical switch. One that physically breaks the connection. For a camera, a built-in cover seems like a fine idea.

The Lenovo P52 models I ordered for my company have a physical slider that covers the camera. This is the 100% sure way nothing can see out of it. Too bad the microphone doesn't have the same level of assuredness. But it's also Lenovo who's already been caught doing hardware spying so...

it's ok, I thought the lenovo service engine would quietly uninstall itself after a few months. :)

This is what I have on my Dell Precision work laptop.

It sounds like they have a physical switch. This module is able to read the switch state and set some indicator LEDs accordingly.

But the kill switch itself is physical.

Here you go: https://puri.sm/products/librem-14

This seems a lot similar to hardware switches for Wi-Fi and Bluetooth devices, which are handled by rfkill. Of course, this adds support for microphone and webcam now, but wouldn't it make sense to extend rfkill? To me the purpose of these hardware switches seems close enough to be handled by a generic framework.

Well, we're still waiting for the fingerprint driver :p

I've been happily using Dells with Linux for... 15 years or so? It's a great option as it comes out of the box working pretty well. Happy to see this.

Sure hope it is actual hardwired, and not hardware with an updatable firmware chip controlling the LED like apple used to do.

https://grahamcluley.com/webcam-spying-without-turning-led-r...

Are there not hooks to turn off power in the kernel to such devices?

if (privacy_button == 1) { set_blinkenlights(0); forward_all_traffic_to_NSA(); }

if privacy_button ON set_blinkenlights_ON forward_all_traffic_to_NSA

I prefer a switch that physically disconnects the wire. Thanks.

Looks at thinkpad X1, has this already, shrugs.

I have a ThinkPad X1 and it doesn't have any hardware switches.

My thinkpad T490 has a "think shutter" which is basically a killswitch / cover for the webcam. Not sure if it mutes the mike or not. AFAIK, this is an optional feature that might not exist on all models.

Of course, you can always disassemble the laptop and unplug the webcam and microphone from the motherboard.

https://www.cnet.com/news/lenovo-thinkpad-laptops-now-let-yo...

If you get an X1 with the 4k touch screen, there's no camera cover or switch.

> The Dell privacy driver sent out on Tuesday for the Linux kernel is about manipulating the relevant LEDs and tracking the status of the hardware-based controls where as the actual toggling of the audio/video support is handled by the hardware.

This is incorrectly designed: the LEDs must be hardware-driven, not software driven. Otherwise malicious software could turn off the LED when the camera and microphone are running.

> the actual toggling of the audio/video support is handled by the hardware.

It's right in the line you quoted.

But the LED indicating the state isn’t. That’s a problem. All you really need to do is make the LED a liar and the user has no idea if their mic is on or not.

Yeah, that's not a good scenario. But they could also just check the physical switch, which cannot lie.

I think that you (and others!) must have misread: I did not write that malicious software would turn on the hardware — I wrote that it 'could turn off the LED when the camera and microphone are running.'

What I mean is that a user could leave the hardware switches in the microphone- or camera-on positions, but malicious software could turn off the LEDs, so that the user would think he had privacy but in fact did not.

Reply on news.ycombinator.com