HDMI-related threats in Qubes OS
555 views
Skip to first unread message
Vít Šesták
Apr 1, 2017, 4:58:17 PM4/1/17
to qubes-users
Hello,
I've realized that HDMI offers not only graphical/sound output, but also many inputs. Well, some inputs are expected (listing of available output modes etc. works AFAIK even with VGA), but others can be more or less surprising:
* audio return channel
* CEC
* ethernet (!)
* maybe even more
Let's assume I have connected an untrusted HDMI device to my laptop with QubesOS. I am aware that screen output will be passed to untrusted device (e.g., I don't read private e-mail on the screen, but maybe I show some public presentation). What can happen if the device is malicious? Can it pass compressed or otherwise complex sound input to dom0? Can it control my laptop over CEC? Can it connect dom0 to network? Will dom0 ignore the HDMI network? Can anything else bad happen? (Yes, the device can pass too high voltage to my laptop, but this is not the kind of attack I can reasonably resolve.)
Maybe you assume that screen should be trusted. This is not always the case. Let's assume we connect to our laptop variously trusted HDMI output devices, ranging from private external screen (most trusted screen) to shared internet-connected and DVB-connected TV with outdated crappy firmware (least trusted). If you are interested in digital TV security, look at https://www.bleepingcomputer.com/news/security/about-90-percent-of-smart-tvs-vulnerable-to-remote-hacking-via-rogue-tv-signals/ . As mentioned above, need of connecting laptop to an untrusted HDMI output is pretty reasonable provided you respect the level of trust of the screen.
Regards,
Vít Šesták 'v6ak'
I've realized that HDMI offers not only graphical/sound output, but also many inputs. Well, some inputs are expected (listing of available output modes etc. works AFAIK even with VGA), but others can be more or less surprising:
* audio return channel
* CEC
* ethernet (!)
* maybe even more
Let's assume I have connected an untrusted HDMI device to my laptop with QubesOS. I am aware that screen output will be passed to untrusted device (e.g., I don't read private e-mail on the screen, but maybe I show some public presentation). What can happen if the device is malicious? Can it pass compressed or otherwise complex sound input to dom0? Can it control my laptop over CEC? Can it connect dom0 to network? Will dom0 ignore the HDMI network? Can anything else bad happen? (Yes, the device can pass too high voltage to my laptop, but this is not the kind of attack I can reasonably resolve.)
Maybe you assume that screen should be trusted. This is not always the case. Let's assume we connect to our laptop variously trusted HDMI output devices, ranging from private external screen (most trusted screen) to shared internet-connected and DVB-connected TV with outdated crappy firmware (least trusted). If you are interested in digital TV security, look at https://www.bleepingcomputer.com/news/security/about-90-percent-of-smart-tvs-vulnerable-to-remote-hacking-via-rogue-tv-signals/ . As mentioned above, need of connecting laptop to an untrusted HDMI output is pretty reasonable provided you respect the level of trust of the screen.
Regards,
Vít Šesták 'v6ak'
Chris Laprise
Apr 1, 2017, 5:52:26 PM4/1/17
to Vít Šesták, qubes-users
the GPU) would be a reasonable first step in addressing the issue. It
may also be possible to disable HDMI ports in favor of simpler ones like
VGA. I'm not sure how much input DVI and Displayport allow, but I think
there's a chance that DVI is similar to VGA in this regard.
--
Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Vít Šesták
Apr 2, 2017, 3:42:16 AM4/2/17
to qubes-users
Yes, disabling those features can prevent thise threats. But I wonder if Qubes does this by default or if I can disable it manually.
I have also an idea how to disable it, but I am unsure if it will work properly: Connect laptop HDMI port -> HDMI to DVI -> DVI to HDMI -> TV HDMI port. But since no conversion is needed, you might end up with full HDMI connection.
Related quotation: “HDMI implements the EIA/CEA-861 standards, which define video formats and waveforms, transport of *compressed*, uncompressed, and LPCM audio, auxiliary data, and implementations of the VESA EDID.[5][6](p. III) *CEA-861 signals carried by HDMI are electrically compatible with the CEA-861 signals used by the digital visual interface (DVI). No signal conversion is necessary*, nor is there a loss of video quality when a DVI-to-HDMI adapter is used.[6](§C)” (https://en.m.wikipedia.org/wiki/HDMI, emphasis is mine)
My notes on this:
1. Compressed audio is not what I want for Audio return channel :(.
2. The [6](§C) links to Appendix C of HDMI spec (see http://www.microprocessor.org/HDMISpecification13a.pdf ), which defines *bidirectional* compatibility level between HDMI and DVI.
Regards,
Vít Šesták 'v6ak'
I have also an idea how to disable it, but I am unsure if it will work properly: Connect laptop HDMI port -> HDMI to DVI -> DVI to HDMI -> TV HDMI port. But since no conversion is needed, you might end up with full HDMI connection.
Related quotation: “HDMI implements the EIA/CEA-861 standards, which define video formats and waveforms, transport of *compressed*, uncompressed, and LPCM audio, auxiliary data, and implementations of the VESA EDID.[5][6](p. III) *CEA-861 signals carried by HDMI are electrically compatible with the CEA-861 signals used by the digital visual interface (DVI). No signal conversion is necessary*, nor is there a loss of video quality when a DVI-to-HDMI adapter is used.[6](§C)” (https://en.m.wikipedia.org/wiki/HDMI, emphasis is mine)
My notes on this:
1. Compressed audio is not what I want for Audio return channel :(.
2. The [6](§C) links to Appendix C of HDMI spec (see http://www.microprocessor.org/HDMISpecification13a.pdf ), which defines *bidirectional* compatibility level between HDMI and DVI.
Regards,
Vít Šesták 'v6ak'
Chris Laprise
Apr 2, 2017, 7:49:05 AM4/2/17
to Vít Šesták, qubes-users
On 04/02/2017 03:42 AM, Vít Šesták wrote:
> Yes, disabling those features can prevent thise threats. But I wonder
> if Qubes does this by default or if I can disable it manually.
We may want to open an issue for this, or at least a thread in
> Yes, disabling those features can prevent thise threats. But I wonder
> if Qubes does this by default or if I can disable it manually.
qubes-developer.
>
> I have also an idea how to disable it, but I am unsure if it will
> work properly: Connect laptop HDMI port -> HDMI to DVI -> DVI to
> HDMI -> TV HDMI port. But since no conversion is needed, you might
> end up with full HDMI connection.
>
> Related quotation: “HDMI implements the EIA/CEA-861 standards, which
> define video formats and waveforms, transport of *compressed*,
> uncompressed, and LPCM audio, auxiliary data, and implementations of
> the VESA EDID.[5][6](p. III) *CEA-861 signals carried by HDMI are
> electrically compatible with the CEA-861 signals used by the digital
> visual interface (DVI). No signal conversion is necessary*, nor is
> there a loss of video quality when a DVI-to-HDMI adapter is
> used.[6](§C)” (https://en.m.wikipedia.org/wiki/HDMI, emphasis is
> mine)
on computers, just that HDMI ports can output to DVI displays. But it
would be good to know what an HDMI-capable monitor can do, for instance,
if a DVI-only card is plugged into one of its DVI ports.
>
> My notes on this:
>
> 1. Compressed audio is not what I want for Audio return channel :(.
> 2. The [6](§C) links to Appendix C of HDMI spec (see
> http://www.microprocessor.org/HDMISpecification13a.pdf ), which
> defines *bidirectional* compatibility level between HDMI and DVI.
>
> Regards, Vít Šesták 'v6ak'
>
don't think it matters... or its a feature you want to keep.
What we need is a breakdown of the supported protocols along with a
description of their interactivity and flow.
haaber
Apr 2, 2017, 11:36:21 AM4/2/17
to qubes...@googlegroups.com
> I think having a graphics driver that disables any auxiliary modes (on
> the GPU) would be a reasonable first step in addressing the issue. It
> may also be possible to disable HDMI ports in favor of simpler ones like
> VGA. I'm not sure how much input DVI and Displayport allow, but I think
> there's a chance that DVI is similar to VGA in this regard.
communication build-in (google: vga & I2C). Bernhard
P.S: A side remark is that this may be turned in a feature rather than a
problem : it is a way to replace usb for some applications (yubikey type
cards for example, where transmission speed is not a problem).
Vít Šesták
Apr 2, 2017, 5:15:11 PM4/2/17
to qubes-users
> We may want to open an issue for this, or at least a thread in
qubes-developer.
IMHO not at this time:
qubes-developer.
* Now, we don't know the current state. There might be nothing to change.
* AFAIR users/devel distinction is mostly based on stable/devel versions. Since this question does not address any specific version, it is probably OK to be in users list.
* Developers seem to read both lists.
> I don't believe this means that HDMI features carry over to DVI outputs
> If the compression is only in one direction (out to the display) then I don't think it matters
> even good-old VGA has a bidirecional serial
communication build-in
> A side remark is that this may be turned in a feature rather than a problem
Regards,
Vít Šesták 'v6ak'
Andrew
Apr 6, 2017, 7:44:29 AM4/6/17
to qubes...@googlegroups.com
Chris Laprise:
It's a bit impractical, but how about an HDMI firewall?
A Pynq-Z1 board can be had fairly cheap ($230 normally, $65 for
students), and implementing a dumb framebuffer copy with simple
open-source components is just a matter of ~10 lines of Python.
Github: https://github.com/Xilinx/PYNQ
Board shop:
http://store.digilentinc.com/pynq-z1-python-productivity-for-zynq/
Documentation doing exactly this:
https://pynq.readthedocs.io/en/latest/9_base_overlay_video.html
(no affiliation with any of the above)
Andrew
A Pynq-Z1 board can be had fairly cheap ($230 normally, $65 for
students), and implementing a dumb framebuffer copy with simple
open-source components is just a matter of ~10 lines of Python.
Github: https://github.com/Xilinx/PYNQ
Board shop:
http://store.digilentinc.com/pynq-z1-python-productivity-for-zynq/
Documentation doing exactly this:
https://pynq.readthedocs.io/en/latest/9_base_overlay_video.html
(no affiliation with any of the above)
Andrew
Vít Šesták
Apr 9, 2017, 9:42:45 AM4/9/17
to qubes-users
Well, there seems to be a cheaper way to do roughly the same. In a nutshell, you just ensure there is no wire for those two things:
* HEAC+ (audio return channel plus ethernet). HEAC+ is optional and thus safe to remove.
* CEC (remote control input) – This one is a bit more tricky. While CEC is also optional, its wiring is reportedly (via Wikipedia) mandatory. I haven't found this in specification. Maybe CEC wire is mandatory for cables (as this is in 1.0 specification), but can be completely ignored in both parties. Theoretically, the worst what can (but hopefully won't) happen is downgrade to single-link digital DVI, effectively restricting the resolution to 1920 × 1200 @ 60 Hz, see below. OTOH, if you don't want to cut CEC, my brief look suggests just minimal attack surface.
Removing them will keep only two inputs you can hardly get rid of:
* DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small.
* HotPlug/HEAC- (PIN 19) – I believe it will work just as hotplug detection if HEAC+ is missing. So, virtually no attack surface.
How to practically cut the wire(s)? You don't have to actually cut the cable etc. There are few easy options:
a. Use HDMI-to-DVI and then DVI-to-HDMI, both should be passive converters. According to pinout at http://pinouts.ru/visual/gen/hdmi_dvi_cable.jpg , it seems to cut just the two input wires, i.e., it would do exactly what we want. While this looks like converting to single-link DVI and back, passive converters will probably allow full HDMI without the features we want to get rid of.
b. Use an older cable without HEAC+ wire. According to the specification, they should exist, but I am not sure if you can find a new one. Useful for home TV, since it is you who buys the cable. However, such cable will probably still have CEC. On the other hand, brief look at CEC does not suggest a large attack surface there.
c. Use cable without CEC wire. It is probably nonstandard, but it seems to actually exist: https://www.pulse-eight.com/p/110/cec-less-hdmi-cable. It is not sure if the cable includes HEAC+ wire ir not.
I suggest verifying the wiring by ohmmeter.
“Cutting” wires might be also better from security perspective than proxy, but it depends. When the proxy is implemented carefully, it might even absorb attack surface of DDC. It also could protect the device (e.g., Smart TV) from attacks from compromised laptop, but this is probably slightly off this topic.
## Should Qubes handle this?
I believe that Qubes should care about it partialy, but the developers cannot do all for you.
First, QubesOS should ignore HDMI ethernet and maybe some other inputs (CEC and ARC) from HDMI. Maybe it already ignores all network devices connected to dom0, but I haven't seen anything that confirms this. Failure to ignore HDMI network in dom0 could make QubesOS more vulnerable to attacks over HDMI than conventional distros are, especially when dom0 is based on EOLed Fedora version.
On the other hand, QubesOS probably cannot resolve this exposure in full extent. Imagine an input being processed by GPU firmware and then with GPU driver and then rejected by QubesOS. You see, the rejection by QubesOS does not necessarily prevent processing of the input by some parsers running with absolute privileges, either dom0 or DMA-enabled device handled by dom0. QubesOS will hardly fix them and I consider it to be outside of QubesOS responsibilities.
Regards,
Vít Šesták 'v6ak'
* HEAC+ (audio return channel plus ethernet). HEAC+ is optional and thus safe to remove.
* CEC (remote control input) – This one is a bit more tricky. While CEC is also optional, its wiring is reportedly (via Wikipedia) mandatory. I haven't found this in specification. Maybe CEC wire is mandatory for cables (as this is in 1.0 specification), but can be completely ignored in both parties. Theoretically, the worst what can (but hopefully won't) happen is downgrade to single-link digital DVI, effectively restricting the resolution to 1920 × 1200 @ 60 Hz, see below. OTOH, if you don't want to cut CEC, my brief look suggests just minimal attack surface.
Removing them will keep only two inputs you can hardly get rid of:
* DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small.
* HotPlug/HEAC- (PIN 19) – I believe it will work just as hotplug detection if HEAC+ is missing. So, virtually no attack surface.
How to practically cut the wire(s)? You don't have to actually cut the cable etc. There are few easy options:
a. Use HDMI-to-DVI and then DVI-to-HDMI, both should be passive converters. According to pinout at http://pinouts.ru/visual/gen/hdmi_dvi_cable.jpg , it seems to cut just the two input wires, i.e., it would do exactly what we want. While this looks like converting to single-link DVI and back, passive converters will probably allow full HDMI without the features we want to get rid of.
b. Use an older cable without HEAC+ wire. According to the specification, they should exist, but I am not sure if you can find a new one. Useful for home TV, since it is you who buys the cable. However, such cable will probably still have CEC. On the other hand, brief look at CEC does not suggest a large attack surface there.
c. Use cable without CEC wire. It is probably nonstandard, but it seems to actually exist: https://www.pulse-eight.com/p/110/cec-less-hdmi-cable. It is not sure if the cable includes HEAC+ wire ir not.
I suggest verifying the wiring by ohmmeter.
“Cutting” wires might be also better from security perspective than proxy, but it depends. When the proxy is implemented carefully, it might even absorb attack surface of DDC. It also could protect the device (e.g., Smart TV) from attacks from compromised laptop, but this is probably slightly off this topic.
## Should Qubes handle this?
I believe that Qubes should care about it partialy, but the developers cannot do all for you.
First, QubesOS should ignore HDMI ethernet and maybe some other inputs (CEC and ARC) from HDMI. Maybe it already ignores all network devices connected to dom0, but I haven't seen anything that confirms this. Failure to ignore HDMI network in dom0 could make QubesOS more vulnerable to attacks over HDMI than conventional distros are, especially when dom0 is based on EOLed Fedora version.
On the other hand, QubesOS probably cannot resolve this exposure in full extent. Imagine an input being processed by GPU firmware and then with GPU driver and then rejected by QubesOS. You see, the rejection by QubesOS does not necessarily prevent processing of the input by some parsers running with absolute privileges, either dom0 or DMA-enabled device handled by dom0. QubesOS will hardly fix them and I consider it to be outside of QubesOS responsibilities.
Regards,
Vít Šesták 'v6ak'
cooloutac
Apr 9, 2017, 2:23:05 PM4/9/17
to qubes-users
We entering the world of smart monitors how scary is that, gonna be no choice soon.
Jean-Philippe Ouellet
Apr 9, 2017, 2:49:47 PM4/9/17
to Vít Šesták, qubes-users
On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták
<groups-no-private-mail--con...@v6ak.com>
wrote:
Having the display device report its supported resolutions lets local
config managers display a list of resolutions to choose from, but the
VGA controller is free to just try to output whatever resolution it
wants. The driver does not inform the display device of what
resolution it is using via some out-of-band protocol, this information
is trivially inferred by the number of pixel clocks between the front
& back porches of the vsync & hsync signals. In 2017 you can't really
damage devices by providing invalid signals (or I would have most
definitely broken some things in the process of developing my own VGA
controller), in practice the device usually just reports "signal out
of range" or equivalent.
Back-reporting via i2c is nice and convenient, but by no means
required for things to work. You can just try best resolution you
want, and if it doesn't work then keep trying others until it works.
<groups-no-private-mail--con...@v6ak.com>
wrote:
>
> * DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small.
Note that this is not strictly necessary for things to work though.
> * DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small.
Having the display device report its supported resolutions lets local
config managers display a list of resolutions to choose from, but the
VGA controller is free to just try to output whatever resolution it
wants. The driver does not inform the display device of what
resolution it is using via some out-of-band protocol, this information
is trivially inferred by the number of pixel clocks between the front
& back porches of the vsync & hsync signals. In 2017 you can't really
damage devices by providing invalid signals (or I would have most
definitely broken some things in the process of developing my own VGA
controller), in practice the device usually just reports "signal out
of range" or equivalent.
Back-reporting via i2c is nice and convenient, but by no means
required for things to work. You can just try best resolution you
want, and if it doesn't work then keep trying others until it works.
Andrew David Wong
Apr 9, 2017, 11:56:25 PM4/9/17
to Vít Šesták, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2017-04-01 13:58, Vít Šesták wrote:
> Hello,
> I've realized that HDMI offers not only graphical/sound output, but also many inputs. Well, some inputs are expected (listing of available output modes etc. works AFAIK even with VGA), but others can be more or less surprising:
>
> * audio return channel
> * CEC
> * ethernet (!)
> * maybe even more
>
> [...]
>
Very interesting discussion so far. Cross-linking with tracking issue:
https://github.com/QubesOS/qubes-issues/issues/2743
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY6wJbAAoJENtN07w5UDAwLokQALhQxKKOMRyoMU17XBKT4CFe
btKsznsSREzwoKwOphV0j1KBSijukjDEYVm/SVfLQfxQLRrPq+Eyv3g0D4qsM1AQ
mzfJLB3On8QAq0jydUaoPDqApgKXYQQ7CKwt016p1+VUb76UR+O+89oDlISBYfiw
7qBq2gwz+Lc3Fei+27pEv22HxXSkxtNZMKtzKiMgXou2l/H3eqWvpYOlbtzWCU1p
gtyj+4sVfJ9YGKWvutN/DzOyIXb1sp0DpzaZCGGpq/5NCKM5Ufg+EYbxCAduDxp/
m0sxFVnRhwcIP4zGGoMW5RHnZtwBHLP6llP55UalWaEolVH6nsS7kRELmfgYm7fw
/sALreuOh/TOv2fFsDN5/Qrw/sFq3yIzQn5NHfxjYnSF5+uGWTEqa854nTPIIQR4
KFPb/BsbLPGoA+f+zDOCcKGBnTEoYpy6LL8OmaYcIODqZkDRQlK0txs4F0DHdob9
+zGwXIj94eB6XdIUACCz2kZeu7hXDRcFHlDuJ5WHn/Effuy45DQEbCztb0vDtAxd
XH7mZ19Hz6GvkCzqNp9R5BSLeubDKbCx1HAmdmaa0cxsyUKt/UHIYthSrMKvPfPF
GTexdTzomHs7v1LlOGT2TnYWX0xowtVWvTBFinTXusw9wfLdj7BN/REFEVDaOT/d
no3IYSVHkscO/TcNGMcI
=PAeU
-----END PGP SIGNATURE-----
Hash: SHA512
On 2017-04-01 13:58, Vít Šesták wrote:
> Hello,
> I've realized that HDMI offers not only graphical/sound output, but also many inputs. Well, some inputs are expected (listing of available output modes etc. works AFAIK even with VGA), but others can be more or less surprising:
>
> * audio return channel
> * CEC
> * ethernet (!)
> * maybe even more
>
>
Very interesting discussion so far. Cross-linking with tracking issue:
https://github.com/QubesOS/qubes-issues/issues/2743
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJY6wJbAAoJENtN07w5UDAwLokQALhQxKKOMRyoMU17XBKT4CFe
btKsznsSREzwoKwOphV0j1KBSijukjDEYVm/SVfLQfxQLRrPq+Eyv3g0D4qsM1AQ
mzfJLB3On8QAq0jydUaoPDqApgKXYQQ7CKwt016p1+VUb76UR+O+89oDlISBYfiw
7qBq2gwz+Lc3Fei+27pEv22HxXSkxtNZMKtzKiMgXou2l/H3eqWvpYOlbtzWCU1p
gtyj+4sVfJ9YGKWvutN/DzOyIXb1sp0DpzaZCGGpq/5NCKM5Ufg+EYbxCAduDxp/
m0sxFVnRhwcIP4zGGoMW5RHnZtwBHLP6llP55UalWaEolVH6nsS7kRELmfgYm7fw
/sALreuOh/TOv2fFsDN5/Qrw/sFq3yIzQn5NHfxjYnSF5+uGWTEqa854nTPIIQR4
KFPb/BsbLPGoA+f+zDOCcKGBnTEoYpy6LL8OmaYcIODqZkDRQlK0txs4F0DHdob9
+zGwXIj94eB6XdIUACCz2kZeu7hXDRcFHlDuJ5WHn/Effuy45DQEbCztb0vDtAxd
XH7mZ19Hz6GvkCzqNp9R5BSLeubDKbCx1HAmdmaa0cxsyUKt/UHIYthSrMKvPfPF
GTexdTzomHs7v1LlOGT2TnYWX0xowtVWvTBFinTXusw9wfLdj7BN/REFEVDaOT/d
no3IYSVHkscO/TcNGMcI
=PAeU
-----END PGP SIGNATURE-----
Vít Šesták
Apr 10, 2017, 3:28:05 PM4/10/17
to qubes-users
> what about vga or dvi wires?
Frankly, my main interest is HDMI. But I have briefly looked at VGA and DVI pinouts. It seems that the only input channels are hotplug (if you count this) and DDC (for resolutions etc.). Plus older VGA seems to have some pre-DDC mechanism called “Monitor ID”. For VGA, you can see scheme http://pinouts.ru/Video/VGA15_pinout.shtml . The “Dir” column is helpful, though it seems to be incorrect at line “I2C bidirectional data line”.
> Qubes already ignores hdmi sound driver in my case lol.
> Because really how can we even trust its hardware, its another separate pc outside of qubes.
> Same goes for printers if you using it, you already giving up some privacy regardless of Qubes.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
Apr 10, 2017, 3:35:16 PM4/10/17
to qubes-users, groups-no-private-mail--con...@v6ak.com
On Sunday, April 9, 2017 at 8:49:47 PM UTC+2, Jean-Philippe Ouellet wrote:
> On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták
> <…@v6ak.com>
> On Sun, Apr 9, 2017 at 9:42 AM, Vít Šesták
> wrote:
> >
> > * DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small.
>
> Note that this is not strictly necessary for things to work though.
For VGA, it seems to be clearly true, as DDC was added some time after initial VGA release.
> >
> > * DDC (PIN 15+16) – needed for getting the resolution etc., present even in current version of VGA. While there is some attack surface, it seems to be rather small.
>
> Note that this is not strictly necessary for things to work though.
But I am not sure if the same applies to HDMI or even for DVI. They don't seem to be designed to work without DDC.
Regards,
Vít Šesták 'v6ak'
cooloutac
Apr 11, 2017, 12:13:18 PM4/11/17
to qubes-users
Vít Šesták
May 7, 2017, 2:14:43 PM5/7/17
to qubes-users
After some while of inactivity, I've made an experiment and successfully created an HDMI “condom”. It is the most universal variant intended for connecting a laptop to some HDMI male.
Ingredients: HDMI-male to DVI-female short cable + DVI-male to HDMI-female adaptor, both are passive.
Price: Roughly $10 + shipping.
Measurements with ohmmeter: I picked HDMI schema from Wikipedia (and confused male/female) and checked what pins are connected and what pins aren't. As expected, CEC and HEAC+ pins are not connected. Surprisingly, also some (all?) shields weren't connected. Maybe this is due to cheap nature on one or both parts.
Validation with HDMI TV: With Qubes 3.2, video output works, while sound output doesn't. With Fedora 25 (and hopefully also with Qubes 4), both audio and video works. Audio output is something that should not theoretically work with pure DVI, so I believe it actually uses HDMI.
What can be tested: I haven't has opportunity to test high-resolution output, which is something that should not work with single-link DVI. It should theoretically work with my HDMI “condom”, but I can offer nothing but theory there at the moment.
Regards,
Vít Šesták 'v6ak'
Ingredients: HDMI-male to DVI-female short cable + DVI-male to HDMI-female adaptor, both are passive.
Price: Roughly $10 + shipping.
Measurements with ohmmeter: I picked HDMI schema from Wikipedia (and confused male/female) and checked what pins are connected and what pins aren't. As expected, CEC and HEAC+ pins are not connected. Surprisingly, also some (all?) shields weren't connected. Maybe this is due to cheap nature on one or both parts.
Validation with HDMI TV: With Qubes 3.2, video output works, while sound output doesn't. With Fedora 25 (and hopefully also with Qubes 4), both audio and video works. Audio output is something that should not theoretically work with pure DVI, so I believe it actually uses HDMI.
What can be tested: I haven't has opportunity to test high-resolution output, which is something that should not work with single-link DVI. It should theoretically work with my HDMI “condom”, but I can offer nothing but theory there at the moment.
Regards,
Vít Šesták 'v6ak'
Chris Laprise
May 8, 2017, 12:55:30 AM5/8/17
to Vít Šesták, qubes-users
Reply all
Reply to author
Forward
0 new messages