[HN Gopher] Dell Adding Hardware Privacy Driver for Linux
___________________________________________________________________
Dell Adding Hardware Privacy Driver for Linux
Author : reddotX
Score : 187 points
Date : 2020-11-04 12:51 UTC (10 hours ago)
(HTM) web link (www.phoronix.com)
(TXT) w3m dump (www.phoronix.com)
| throwawaymanbot wrote:
| why do they do dumb stuff like this to begin with?
| raimue wrote:
| 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.
| LeonM wrote:
| 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...
| slezyr wrote:
| It looks like `micmute_led_set` does exactly this.
| LeonM wrote:
| 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 wrote:
| 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.45tbmnrqvccbrd2
| k...
|
| Might be copy/paste from another driver or they will
| implement it later.
| adrianmonk wrote:
| 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.
| nazgulsenpai wrote:
| 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.
| tenebrisalietum wrote:
| 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.
| m463 wrote:
| 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)
| jnurmine wrote:
| 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.
| duskwuff wrote:
| > =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.)
| gigatexal wrote:
| Are there not hooks to turn off power in the kernel to such
| devices?
| ReptileMan wrote:
| I prefer a switch that physically disconnects the wire. Thanks.
| rmrfstar wrote:
| 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.
| robocat wrote:
| 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).
| m463 wrote:
| 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
| moftz wrote:
| 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.
| shalabajser wrote:
| if (privacy_button == 1) { set_blinkenlights(0);
| forward_all_traffic_to_NSA(); }
| grovellogic wrote:
| 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...
| tbrock wrote:
| Looks at thinkpad X1, has this already, shrugs.
| caymanjim wrote:
| I have a ThinkPad X1 and it doesn't have any hardware switches.
| SamuelAdams wrote:
| 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...
| caymanjim wrote:
| If you get an X1 with the 4k touch screen, there's no
| camera cover or switch.
| everdrive wrote:
| 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.
| Nursie wrote:
| 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.
| fsflover wrote:
| Here you go: https://puri.sm/products/librem-14
| eumoria wrote:
| 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...
| m463 wrote:
| it's ok, I thought the lenovo service engine would quietly
| uninstall itself after a few months. :)
| shalabajser wrote:
| if privacy_button ON set_blinkenlights_ON
| forward_all_traffic_to_NSA
| pavon wrote:
| 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.
| davidw wrote:
| 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.
| zeveb wrote:
| > 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.
| lultimouomo wrote:
| > the actual toggling of the audio/video support is handled by
| the hardware.
|
| It's right in the line you quoted.
| donatj wrote:
| 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.
| jaywalk wrote:
| Yeah, that's not a good scenario. But they could also just
| check the physical switch, which cannot lie.
| zeveb wrote:
| 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.
| devenblake wrote:
| "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?
| mastax wrote:
| > 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.
| m463 wrote:
| 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.
| sojuz151 wrote:
| Connect the LED via current mirror to webcam power line? You
| will know when webcam is recording because it draws far more
| power.
| bayindirh wrote:
| 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.
| surround wrote:
| That seems to be an issue with most webcams - the indicator
| light itself can be compromised and disabled.
| mnahkies wrote:
| 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
| LeonM wrote:
| Third party webcams, yes.
|
| Basically any modern laptop with a build-in webcam has a
| hardware controlled LED, not software controlled.
| m463 wrote:
| I don't see that this is necessarily true or easy to figure
| out.
| discreditable wrote:
| 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.
| varispeed wrote:
| 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.
| tw04 wrote:
| >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.
| varispeed wrote:
| 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.
| tw04 wrote:
| 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?
| marcinzm wrote:
| 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.
| weehoo wrote:
| 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...
| marcinzm wrote:
| 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).
| kelnos wrote:
| 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.
| rainingcatndogs wrote:
| I belive you can blacklist that driver if needed.
| Vrondi wrote:
| If it is switched off, then you cannot be surveiled by it.
| Mission accomplished.
| coldtea wrote:
| > _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?
| antoinealb wrote:
| 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.
| lultimouomo wrote:
| 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.
| criddell wrote:
| 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.
| crote wrote:
| 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".
| duskwuff wrote:
| > 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.
| jakobdabo wrote:
| > 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...
| Vrondi wrote:
| 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.
| matheusmoreira wrote:
| 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.
| jackvalentine wrote:
| It's a Chrome extension.
| fouric wrote:
| ...then you just cover the camera and/or mic with a
| physical cover, such a piece of tape.
| boogies wrote:
| > and/or mic
|
| How well would tape work on that?
| ArnoVW wrote:
| 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?
| colejohnson66 wrote:
| 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.
| absolutelyrad wrote:
| > _Why not just wire the LEDs up to the same power line that
| goes to the camera?_
|
| You know why.
| yjftsjthsd-h wrote:
| Lovely; care to enlighten the rest of us?
| hedora wrote:
| It's a rhetorical question. There's no good reason not to
| do it.
|
| The main reason is cost and hardware complexity, which
| would be negligible if the camera asic simply had an "I am
| on" pin to drive an LED. Laptop manufacturers clearly don't
| care about this issue enough to insist that camera and
| audio hardware manufacturers include such a pin on future
| models.
| [deleted]
| dastx wrote:
| 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.
| d33 wrote:
| ...Another LED for the data wire then?
| Kuinox wrote:
| 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.
| sschueller wrote:
| So the NSA/CIA/FBI can enable the camera/mic without you
| knowing.
| tscolari wrote:
| Well, we're still waiting for the fingerprint driver :p
___________________________________________________________________
(page generated 2020-11-04 23:01 UTC)