[HN Gopher] The i.MX8 cannot be deblobbed
___________________________________________________________________
The i.MX8 cannot be deblobbed
Author : pabs3
Score : 113 points
Date : 2023-04-24 08:03 UTC (14 hours ago)
(HTM) web link (www.devever.net)
(TXT) w3m dump (www.devever.net)
| vkoskiv wrote:
| Since the MNT Reform was mentioned in the article, it's worth
| pointing out that the way they handled this was to have HDMI
| disabled by default, and the user can then run a script to re-
| enable HDMI and reboot. When HDMI is disabled, the only non-free
| blob left is the DDR4 controller training blob.
| hlandau wrote:
| Author here. MNT actually went out of their way to make sure
| you could use the device without this blob: rather than do the
| obvious thing and wire up HDMI or DP to the laptop's internal
| display (both of which require the blob), they used the MIPI
| DSI interface and a DSI to eDP converter chip.
|
| But yeah, if you want to use the external HDMI port on the
| laptop, you need the blob.
| pabs3 wrote:
| What does the DSI to eDP converter chip run? Does it have
| internal flash or just a bootrom running the firmware?
| hlandau wrote:
| I don't believe it is known to have any firmware.
| alpha64 wrote:
| Isn't this why the MNT Reform, and possibly others, use a DSI to
| eDP converter - specifically to avoid having to play this game?
| hlandau wrote:
| Author here. Yes - the obvious way to wire up the internal
| display of the MNT Reform would have been to use eDP directly,
| but since that would require use of the blob, they used the
| i.MX8M's MIPI DSI interface instead and used a DSI to eDP
| converter.
| alpha64 wrote:
| Shouldn't you have mentioned this in your article? The way
| the article is written makes it sound like the MNT Reform is
| flawed in a way this clarifies it is not.
| hlandau wrote:
| Not sure what you're referring to. As I state in the
| article:
|
| >Therefore, it is impossible to ever replace the HDMI blob
| used by this device. The device could be used without this
| blob, but you then forego use of the HDMI (or DisplayPort)
| functionality.
|
| If you use the MNT Reform without the blob you can never
| use certain features of the device, namely the external
| HDMI port, so it's not as though the MNT Reform is without
| flaws. In any case the article is about the i.MX8M, not any
| specific device.
| alpha64 wrote:
| You explicitly mention the MNT Reform and the Librem 5,
| which use this chip. I agree that you never say that any
| given device can't work around this, but that is what I
| understood from the way this was presented. I was vaguely
| familiar with the MNT Reform and went looking for that
| converter chip because I thought they had a solution to
| this, which they do.
|
| Perhaps if the last bullet point in the article said
| something about not being able to use HDMI or displayport
| without a converter chip, it would have been clearer to
| me.
| hlandau wrote:
| I've updated the article to clarify this. Thanks for the
| feedback!
| CrampusDestrus wrote:
| It's times like this when I think we could only proceed if
| someone working there "leaked" the code (or, more precisely, a
| functional representation of its logic) to a group of secretive
| reverse-engineers and they came up with a credible clean room
| implementation
| phoe-krk wrote:
| The code is useless without the keys used to sign it; even if
| you get a custom blob, you are unable to have it recognized by
| the device in question. This is tivoization at its finest.
| hlandau wrote:
| Author here. As the comment above notes, it's a leak of the
| signing keys which would be needed to free this. The actual
| blob itself can be reversed and replaced with enough of
| someone's time. The only other prospect is a flaw in the code
| which verifies the signature. The PS3 ECDSA break was an
| amusing example of this (though technically in that case,
| actually a flaw in the signing code, not the verifying code).
| gpderetta wrote:
| WII using strcmp instead of memcmp to verify signatures is
| also a well known (and amusing) case.
| CrampusDestrus wrote:
| But the thing is, if those keys were to be leaked the damage
| would be irrepairable. You could legally donwload the reverse
| engineered firmware and then "acquire" the key and plug it
| in.
| hlandau wrote:
| They won't be leaked, though. With a large western coompany
| like NXP, especially being that it's one with crypto-
| related business units, it's basically guaranteed that the
| keys will be in an HSM. There's always a slight chance
| they're inept and the private key is sitting in someone's
| home directory and they could decide to leak it, but in
| this case the chances seem very low.
|
| Might have better luck with the Taiwanese hardware vendors
| - as I recall a major Taiwanese PC motherboard maker got
| hacked recently and UEFI secure boot keys were taken, so
| they probably weren't storing them in an HSM and don't have
| proper security practices in place for cryptographic
| material.
| p0w3n3d wrote:
| I keep forgetting how many people do what horrendous amount of
| work to keep devices and systems free or at least possible to be
| free.
| [deleted]
| formerly_proven wrote:
| I imagine this is required for HDCP support, but why is it
| impossible to run without a blob and no HDCP support?
| hlandau wrote:
| Author here. Not all HDMI/HDCP implementations work like this.
| Basically, the designer of the SoC (NXP) will have licenced an
| HDMI/HDCP IP block from some company selling such IP. It looks
| like NXP licenced their HDMI/HDCP IP from Cadence in this case,
| a major provider of silicon IP.
|
| So this particular HDMI/HDCP implementation is designed to
| require this signed blob in order for it to function. Could
| Cadence have designed it so you can use it without HDCP without
| this blob, or use an unsigned blob and forego HDCP support,
| probably. But they didn't, so that's the situation.
| masklinn wrote:
| I would assume it's because the i.MX8 has no path to not
| support HDCP, so if you're using it your choices are not
| "nothing, HDMI, or HDMI + HDCP" it's "nothing, or HDMI + HDCP".
|
| You can find old posts on the NXP forums talking about how
| disabling HDCP kills HDMI.
|
| If the chip can do TB / DisplayPort, you could add a separate
| DP -> HDMI converter, but obviously that increases your costs.
| nyanpasu64 wrote:
| So it's impossible to get a HDMI signal out of the chip which
| can be read by a regular monitor or capture card without
| decryption keys, even for displaying non-movie images and
| GUIs? This is utterly disgusting. Or does HDCP turn off when
| talking to a non-HDCP (eg. DVI) display?
| azalemeth wrote:
| This is a wonderful example of how deeply ingrained Hollywood is
| into design cultures. The whole reason for this is to preserve
| the 'security' of HDCP - an anti-consumer technology at its
| finest.
|
| Note that, despite this, you can still find basically any movie
| you want on popular websites - the only people who suffer are
| paying consumers.
| omeid2 wrote:
| DRM is a lot more about manufacturers than consumers. This
| isn't a justification, but rather adding a wider view of the
| issue.
|
| See the licensing costs here. What is the
| cost for express processing? $5,000 USD per
| "Multiplier". What is the smallest
| number of Device Key sets that can be purchased?
| The quantities and prices for key orders are listed below:
| Description Cost (USD) HDCP 1.x Transmitter or
| Receiver Key - Qty of 10,000 $2,000 USD HDCP 1.x
| Transmitter or Receiver Key - Qty of 100,000 $5,000 USD
| HDCP 1.x Transmitter or Receiver Key - Qty of 1,000,000
| $10,000 USD HDCP 2.x Annual Source Key Fee - Up to
| 100/year $500 USD HDCP 2.x Annual Source Key Fee - Up
| to 1K per year $1,000 USD HDCP 2.x Annual Source Key
| Fee - Up to 10K per year $2,000 USD HDCP 2.x Annual
| Source Key Fee - Up to 100K per year $5,000 USD HDCP
| 2.x Annual Source Key Fee - Up to 1M per year $10,000 USD
| HDCP 2.x Annual Source Key Fee - For quantities over 1M per
| year $20,000 USD HDCP 2.x Receiver Key - Qty of
| 10,000 $2,000 USD HDCP 2.x Receiver Key - Qty of
| 100,000 $5,000 USD HDCP 2.x Receiver Key - Qty of
| 1,000,000 $10,000 USD
|
| https://www.digital-cp.com/faqs
| formerly_proven wrote:
| "digital-cp.com" is kind of an unfortunate domain name.
| Fnoord wrote:
| Heh, yeah. But one form of cp isn't socially accepted at
| all, while the other one is. The one which is, is much much
| much easier to find.
|
| Now that I think of it: it (rampant piracy of audio and
| video) is a great practical example to teens why they
| should not share pictures of themselves naked. If someone
| wants to, it gets spread. Even if there's 'copyright
| protection'. In some circles, Snapchat is seen as seriously
| private. Which is very ignorant, and has lead to situations
| like blackmailing and retaliation porn.
| baybal2 wrote:
| [dead]
| luch wrote:
| Totally, DRM technologies aims to control the distribution,
| the consumer side is almost irrelevant here.
|
| the DRM industry gets away with it since consumers don't care
| about openness or libre, they just want to watch videos in hi
| definition.
| webmobdev wrote:
| What choice do you think consumers have?
| Am4TIfIsER0ppos wrote:
| Consumers have the choice to pirate. Nay. The moral
| imperative. Fuck hollywood.
| retrocryptid wrote:
| COPYRIGHT INFRINGEMENT IS YOUR BEST ENTERTAINMENT VALUE.
| Fnoord wrote:
| Or watch a lower quality Widevine certified (L3 is easy
| to reach), or watch linear TV, or circumvent copyright
| protection such as DeCSS.
| dismalpedigree wrote:
| Arg!
| luch wrote:
| They have to choice to elect representatives that will
| legiferate on it, such as the EU with Apple regarding
| USB-C or app store sideloading.
| michaelt wrote:
| So should I be voting Democrat or Republican to get that?
| /s
| nathanlied wrote:
| You should vote to join the EU, maybe it'll work!
| 0cVlTeIATBs wrote:
| Theoretically, "thrown away" votes for the Pirate party
| would get attention from red and/or blue both if there
| were enough of them.
| PeterisP wrote:
| The licensing costs you list are tiny and irrelevant as a
| revenue stream, and seem just like something in the ballpark
| to cover the overhead (legal, etc) of that licensing and
| distribution. For a manufacturer making a million devices, a
| literal 1 cent per device is not a major change, and on
| Hollywood scale collecting a five-figure amount per
| manufacturer isn't meaningful either.
| captainmuon wrote:
| My previous company made monitors, and my chinese colleague
| told me this rumor that some of the mainboard vendors would
| offer "real" or "fake" HDCP, fake meaning that you could turn
| the monitor mainboard into a HDCP stripper.
|
| Now I don't know how they could offer this, and I don't know
| how a new HDCP key is issued when a leaked one is blacklisted.
| I assume the engineer just didn't care or maybe the key was
| already old.
| mschuster91 wrote:
| HDCP is broken so thoroughly that keys don't matter any more,
| and revoking them would break hardware on a scale that would
| put the F00F bug remediation cost to shame.
| Marazan wrote:
| Can't say FOOF without thinking about:
| https://www.science.org/content/blog-post/things-i-won-t-
| wor...
| pjc50 wrote:
| Undoubtedly the whole HDMI implementation will be unlicensed,
| and they will be using the master key that's been leaked
| since 2010.
|
| There are reportedly lots of HDMI "splitters" that defeat
| HDCP too.
| squarefoot wrote:
| Some HDMI splitters commonly sold online are reportedly
| capable of stripping HDCP protection. I could never verify
| that, so I cannot point to a specific model, but a simple
| search seems to confirm that.
| benj111 wrote:
| They do, I got one for an old TV (I say old, it had hdmi)
| when a new Amazon fire dongle wouldn't work.
| draw_down wrote:
| [dead]
| ho_schi wrote:
| _Question_.
|
| Why does this also affect Display Port? Is the document elsewhere
| stating that both are intertwined?
|
| It is depressing how "intellectual property" damaged computing.
| Just imaging a critical bug needs fixed in 15 years and the key
| signing utility is not available because ${RANDOM_CORP}
| disappeared. Don't say that couldn't happen: Nokia, Sun, DEC,
| Apple (nearly bankrupt 1998), 3DFX, Aureal and so on. And this
| lists only the ones where the employees are no longer available.
| Other just cancel support. Broadcom - which I know avoid -
| doesn't care anymore about their BLE 4.0 chips and the (security)
| issues.
|
| Seeing how Netflix and others succeeded with a flatrate model -
| which is the actual solution - this is completely unnecessary.
| The authorities missed to create institutional ways for creators
| to collect money, just awkward unfair taxes on harddisks and VHS-
| Tapes. Which streaming did?
| hn8305823 wrote:
| Don't forget how they killed DAT before it even had a chance to
| get going. Consumers were stuck with analog casette mixtapes
| for another decade or more unnecessarily.
|
| The worst part is what it did to indie/amateur musicians. The
| only models allowed to record at 44.1 were "professional" that
| cost a lot more than the very few consumer models that were
| only allowed to do 32k and 48k.
| toast0 wrote:
| > Just imaging a critical bug needs fixed in 15 years and the
| key signing utility is not available because ${RANDOM_CORP}
| disappeared.
|
| It doesn't even need to be a corporation disappeared; it could
| be they decide they don't want to sign things anymore. As a
| application developer you have to make a choice --- how long do
| you want your last and final build to work, knowing it's
| impossible to fix any client side issues after that, and you
| can't extend it later.
| hlandau wrote:
| Both HDMI and DisplayPort can use HDCP. The authors of the
| DisplayPort standard also invented their own clone of HDCP
| called DPCP, but you can also use HDCP over DP, and it seems
| like HDCP is a lot more popular(?). In any case the DRM
| implications (in terms of lockdown and code signing) are the
| same. Though not explicitly mentioned in the screenshots of the
| i.MX8M reference manual shown in the article, reading the rest
| of the manual it's clear DP is affected too. (Which, again, is
| why the MNT Reform forewent the use of the DP interface to
| attach their eDP internal display in favour of a MIPI DSI to
| eDP bridge.)
|
| I certainly agree that restrictive code signing practices like
| these are completely unacceptable. In my view, the 'right to
| repair' movement should encompass a right to any keys needed to
| fix bugs, though I am not optimistic about 'right to repair'
| being interpreted in this way.
|
| Worth noting that while we usually think of DRM as a (patently
| ineffective) way to prevent piracy, in reality it seems to be
| much more about controlling end devices and the manufacturers
| of end devices. I explain more about this here:
| https://news.ycombinator.com/item?id=17588610
| seba_dos1 wrote:
| > (Which, again, is why the MNT Reform forewent the use of
| the DP interface to attach their eDP internal display in
| favour of a MIPI DSI to eDP bridge.)
|
| There's only one display interface capable of driving DP/HDMI
| on i.MX8M, so if they didn't do that they wouldn't have
| external HDMI port.
| ho_schi wrote:
| Thanks.
| noobermin wrote:
| There really is no way out of this beyond regulation? Yet I doubt
| governments will side with consumers on this one (even in Europe)
| given their stance on copyright on behalf of ip holders, so there
| is no way out.
|
| The thing I keep thinking about are things like pace makers and
| other medical devices that become useless implants once biotech
| companies go under. May be today it seems like the company you're
| getting the blobs from will be around but one day it won't be (or
| won't care to be) and then what are you going to do? May be
| something like this or an SBC doesn't matter as severely as a
| pace maker but anytime anyone builds something with these socs
| they run the risk that their product will be a dead weight in 10
| years.
|
| But of course, that doesn't matter for most developers, just
| those of us who want to stop the endless technopollution in tech,
| make things that last, you know.
| RobotToaster wrote:
| Already happening https://spectrum.ieee.org/bionic-eye-obsolete
| noobermin wrote:
| Yes, I was referencing articles like this one and others.
| eru wrote:
| Benign neglect would probably work.
|
| Eventually the technological barriers will be worked around,
| and if the legal systems around the world don't spring into
| action, that's it.
| mardifoufs wrote:
| Europe, and the EU to be more accurate, is rabidly pro
| copyright. They might also be pro consumer, usually, but not
| when discussing copyright. Just look at the EU copyright laws
| that were recently pased. Or the stranglehold copyright lobbies
| have on member states (the music industry in Germany, for
| example)
|
| In general, the US is more lenient and has a broader definition
| of fair use.
| xxpor wrote:
| Germany doesn't even have a general fair use doctrine in the
| first place! It's really horrendous.
|
| Most countries' governments outside the US also assert
| copyright on their own works, which is ridiculous IMO, but is
| a good representation of the entire concept of the US:
| legitimacy is derived from the people themselves. The
| government can't have copyright because The People as a whole
| own the work.
| captainmuon wrote:
| Unless there is an exploitable bug in the bootloader, or the HDMI
| memory locking logic, or someone leaks the key.
|
| Or, cleaner but less "realistic", the people making these things
| just sit down and decide to release the key, or make chips
| without the limitation. I mean it is all man-made, there is no
| physical law saying this can't be done. If you ignore the
| financial and IP dimensions for a second, just on technical
| merits, it is a no-brainer.
| noobermin wrote:
| In a mystical insekai style other world SoC makers should be
| have to release their keys once they decide to discontinue
| their chips or not recommend them for new designs, but alas we
| live in this world.
| eru wrote:
| You'd have to put the keys into escrow in the first place. So
| the makers can't just disappear.
| pbhjpbhj wrote:
| Copyright is supposed to be public protection in exchange
| for works entering the public domain.
|
| Copyright is an automatic right (though I understand you
| still have registration in USA which increases damages
| available) but should not be applied to DRM works that
| haven't had DRM-free copies lodged with a government or
| authority (eg WIPO).
|
| DRM encumbered works cannot ever enter the public domain
| and so cannot fulfill the requirements for copyright.
|
| _This is of course my own personal opinion, unrelated to
| my employment._
| pabs3 wrote:
| Exploiting a flaw in the code would presumably be a DMCA
| violation and the key is likely on a HSM so probably can't be
| leaked or released.
|
| So the only realistic option is to wait for a new hardware
| revision that fixes this, or switch to another SoC.
| kibwen wrote:
| The buried lede:
|
| _> Therefore, it is impossible to ever replace the HDMI blob
| used by this device. The device could be used without this blob,
| but you then forego use of the HDMI (or DisplayPort)
| functionality._
|
| _> Note about the MNT Reform: The MNT Reform went out of its way
| to avoid relying on this blob for its internal display. Rather
| than doing the obvious thing and connecting the i.MX8M 's
| DisplayPort interface to the Embedded DisplayPort (eDP) display
| panel, they connected the internal display by using the i.MX8M's
| MIPI DSI interface (which is unaffected by this blob) to connect
| to a MIPI DSI to eDP converter chip, and then to the display
| (indeed, the fact that they went out of their way to ensure
| people can use the laptop without the blob certainly warrants
| praise). The external HDMI port can't be used without the blob,
| however._
| pabs3 wrote:
| What blobs does the MIPI DSI to eDP converter chip run?
| nrclark wrote:
| Some, probably. But that firmware is self-contained to the
| converter chip, and doesn't have the ability to interact with
| your CPU's various subsystems.
|
| The i.MX8's HDMI core has independent access to the DDR
| memory, peripheral buses, timers, DMAs, and who knows what
| else. It's probably even running an RTOS of some kind, which
| might or might not include network drivers. Malicious
| firmware could compromise the security of your entire device.
|
| It's kind of the same problem that some folks have with
| Intel's IME. It could be fine and secure. Or maybe not, we
| just don't know.
|
| Nobody's saying that the i.MX8's HDMI firmware is malicious.
| It's probably fine. But we also don't know, because we can't
| inspect it. So if you were designing that chip into a
| security-critical setting, you'd have to wonder what might be
| running without your knowledge.
___________________________________________________________________
(page generated 2023-04-24 23:02 UTC)