Live data from Hacker News

The GPU, not the TPM, is the root of hardware DRM

mjg59.dreamwidth.org

481–490 of 493 posts

Re: The GPU, not the TPM, is the root of hardware DRM

#481

Earlier quoted context omitted.

> protecting their IP is a fiduciary duty, This is not the case, unless we are talking about trade secrets, and in case of trade secrets, only applicable to board members and employees.

That's not how copyright works. The copyright owners want to maximize earnings, and the licensees/distributors also want to maximize earnings -- they are typically for-profit businesses, and as such they have a fiduciary duty to maximize earnings. If they think that DRM will help them, they'll want DRM. Of course for music DRM has proven to be pointless. People want to stream music, not buy music, and preserving medi…

> fiduciary duty to maximize earnings

This is not how corporate fiduciary duties work (courts repeatedly ruled there is no explicit responsibility to maximise profits or minimise taxes; Swedish Aktienbolaget are a notable exception there), though it is a common misinterpretation of them.

Re: The GPU, not the TPM, is the root of hardware DRM

#482
post #334

Earlier quoted context omitted.

Back in the day when piracy was quite literally just copy and paste it was a very active scene. But cracking Denuvo takes real skill- and there's no financial reward in it. Back in the 90s bootleg DVDs and CD-ROMs had organised crime making money from it.

Exactly. Cracking Denuvo as a hobby is not something a sane person would do, and the downsides if caught are higher when one is fully employed. At least to me, a decade has passed since I left college and had spare time and energy to tackle such projects just for cred.

I took a cursory look at breaking it and it seems rather trivial in retrospect, just annoying at best since you have to rebuild the executable’s imports, relocations and section headers, along with removing the giant bloat sections that they add (seriously, when the main .text section of a game is 4MB, and then their extra obfuscation sections end up being over 250MB, something is ridiculously wrong.)

Re: The GPU, not the TPM, is the root of hardware DRM

#483

Earlier quoted context omitted.

Do they mean that no OS modification is necessary to read the decrypted media from memory?

Currently, no. But once (undetectable) OS modification is no longer possible, making the undecrypted media unreadable is just a few API restrictions away. In Android phones for example you cannot screenshot banking apps. And if you root (modify the OS of) your phone, banking apps refuse to work.

However, for the question at hand, that's irrelevant: a better (for DRM) solution exists today, and they're already using it.

I'm not saying that the TPM is incapable of being abused by manufacturers and OS authors, but the FSF really weakens their argument when they predicate it on something that's not actually true. Ex falso quodlibet (you may prove anything if you rely on a falsehood).

Re: The GPU, not the TPM, is the root of hardware DRM

#484
post #20

Earlier quoted context omitted.

The end goal is DRM all the way to the screen. No capture cards will be allowed. It's a cat and mouse game, but I wouldn't discount these efforts as a mere speed bump. Screen enforced DRM will make things much harder. A motivated individual with the right tools and hardware hacking know how may be able to jailbreak a screen to record stuff, but that's going to make things out of reach for most people.

With how good modern screens are, and how good cameras are (and how easy both are to hack), you could always play back the video and capture the photons through the air. There was something called Macrovision back in the VHS/DVD days that tried to defeat digital/analog conversion, and I'm sure visual techniques could be devised... But I imagine someone with a good OLED and a good mirrorless camera (or even a cell pho…

Except Cinavia, which worked on audio level, exists: https://en.wikipedia.org/wiki/Cinavia

Although it can only trip on certain devices or media players (mainly Blu-ray players, including PS3 onwards), I did read an idea that suggested Cinavia being placed inside an OS's kernel in a secure enclave to make it system-wide.

Re: The GPU, not the TPM, is the root of hardware DRM

#485
post #460

Earlier quoted context omitted.

> Android devices are fully open and you can reflash them to whatever OS you want. It doesn't matter. Those devices fail hardware remote attestation. > Some remote servers won't give you service if you do that, but nothing is locking you out of your device. The device's purpose is to be used. If it can't be used without giving up things like banks and private communications, it won't be used. Device is not locked, it…

As an example of the excess here: Marriott (the hotel brand) shipped a release of their Android app that refused to run on unlocked devices. It probably didn't impact the majority of (locked) Android devices, so why would Marriott care? And with one app update, a valid user configuration became less capable.

When this remote attestation business started, people tried to minimize its impact by saying only apps that really needed it would use it. Such an absurd argument. Everyone is going to use this technology. It will literally become the default.

Everyone loves cryptography and wants it working in their favor. Everyone. It's great for us when it protects our messages and browsing from surveillance capitalism and warrantless government espionage. It's extremely bad for us when it becomes the policy enforcement tool of corporations and governments.

Remote attestation means we either we run the software which does their bidding and protects their interests and bottom line or we don't participate in society or the economy. Only way it could get worse is if the government starts signing software as well. One day even the goddamn ISPs will refuse to link to our hardware if it fails attestation.

It's literally the end of free computing as we know it. Everything the word "hacker" ever stood for, it's over.

Re: The GPU, not the TPM, is the root of hardware DRM

#486
post #294

Earlier quoted context omitted.

Any computer or phone can play it back I’m sure. It’s just an MP4 file. And with Airplay or an HDMI cable your TV can too?

It's not clear to me how widely Cinavia is actually deployed. The Wikipedia article hasn't really been updated in over a decade, and that's where I'm getting my info from. However, the detection and enforcement can theoretically be done by any device or software that has access to the audio signal. The monitor, the GPU, the playback software, the operating system, etc. could each individually decide not to play the f…

In practice, only licensed Blu-ray players (hardware and software) implement Cinavia. While there was an idea/fear that an OS can implement Cinavia system-wide, that did not happen (yet).

Re: The GPU, not the TPM, is the root of hardware DRM

#487

Earlier quoted context omitted.

> The OS is still managing and abstracting hardware in the same way that it always was. Not at all. The OS is not "managing" anything. It has no direct access to the real hardware. Only the firmware does. The OS is just talking to the API the firmware presents. They're not our devices anymore. They're intel's, nvidia's. They dictate how we use them. The hardware's just sitting there, waiting for the right electrical…

"Managing" and "talking to an API" are not mutually exclusive though. Yes, firmware has continuously become more complex. Yes, if you go back far enough (quite a long ways) there wasn't any. Peripherals have always been a black box that increased in complexity over time. That increase in complexity does not imply a decrease in management complexity on the part of the kernel. Far from it! Modern device drivers are far…

> That increase in complexity does not imply a decrease in management complexity on the part of the kernel.

Complexity is not the point. Control is. The operating system should be in complete control of the system, and it isn't.

Complexity is part of the reason for that. The actual hardware is exceedingly complex, so manufacturers simplify it with firmware that presents a more convenient API.

That's convenient but it means we are no longer in control of the hardware. We merely interface with the convenient abstraction presented to us. It's that abstraction which actually drives the hardware, not our "drivers".

And that obviously becomes a mechanism by which to control us. Access to perfectly good hardware could be denied by the firmware for unacceptable reasons such as market segmentation or copyright enforcement.

> But I don't think gating certain features in the CPU or GPU for the purpose of market segmentation qualifies as dictating how I use my device.

BS. I want to copy stuff. It's not letting me. It's that simple. Some nonsense about "protected video paths".

The hardware is working and able but a fundamental computer operation cannot be performed because the firmware doesn't want to. Computer says no.

> The device driver situation is already nearly unmanageable. Imagine how much worse it would be if the kernel needed to manage every last minute hardware detail down to the model and even sub-model variants.

If that's the cost of maintaining control, we should pay it gladly. Better than growing comfortable with the manufacturer's convenient abstraction which also conveniently allows them to control what we do with "our" machines.

> There are many different nefarious things happening at once.

There is exactly one thing happening here: corporations usurping control of our devices to protect their interests and profits. The means by which they do so are far less important, they are merely details.

These details are irrelevant in the grand scheme of things. It's all about control, about giving you less of it, the minimum amount of it. The exact mechanism by which they do it is irrelevant.

It's always some abstraction, some indirection, a little bit of clever cryptography. Maybe there's an even more privileged hidden OS running on the CPU which can access everything while we can't. Maybe there's some signed firmware running in a completely separate computer in the hardware and that computer acts as a middleman and gatekeeper. It doesn't matter. Our goal should be to take over the functions those components are doing, whatever it is that they do. They should be running our code, doing our bidding.

> Conflating them only serves to confuse the discussion and leads people to (wrongly) believe that there's no need to worry about those weirdos ranting and raving in the corner.

What else is new? Stallman has been warning everyone about exactly this for nearly half a century already and people still treat him like some lunatic religious zealot despite the cyberpunk reality we live in today. Even I made that mistake at some point in my life.

If they won't listen, they'll suffer the consequences. They'll end up living under the control of corporations. Might as well remove the word "hacker" from this website's name because everything it ever stood for is over.

In my opinion, Stallman's mistake is he's way too nice about it. Always speaking softly and being reasonable about everything. Always getting bogged down over precise wording and irrelevant details. GNU has an entire glossary page dedicated to precise wording.

Meanwhile, the entire industry has worked around his ideas by isolating his free software and maintaining control with firmware. To have a truly "freedom respecting" computer with no firmware blobs, you gotta get one from literally decades ago. Because these days everything has firmware which you do not control. If you're lucky. If you aren't, you get something that's literally locked down to the point you have no choice whatsoever. What good is free software if you can't run it? It's worthless. It's worse than worthless: one day you wake up and you realize you were working for free for the corporations who are now profiting off of you while denying you the control you wanted.

It's all very simple. Free computers are subversive weapons. They have the power to literally wipe out entire sections of the economy. They have the power to defeat judges, armies, nations. They are quite literally the most important invention of mankind.

Naturally, corporations and governments will do everything in their power to control what you can do with a computer. First, they reduced computers to toys which could run all programs, except the ones they didn't like. This sort of "computer" is what we are discussing right now. Computers where you can do everything except copy their precious content. They are currently in the process of reducing computers to toys which refuse to run all programs, except the ones they like. That's the mobile landscape. Does it matter that hardware remote attestation is the mechanism by which they're doing it? Not much.

I can barely find the words to describe how disgusted this status quo makes me feel. I know what they're doing and I know they're succeeding. It makes me sick. Like I'm witnessing something great be destroyed due to greed and fear. I feel sick.

If that makes me the weird fellow raving in the corner, so be it. I'll keep raving in every thread about the subject until the day I get banned by dang. There's no point to this site if they win anyway. What good is Hacker News if you can't hack?

Re: The GPU, not the TPM, is the root of hardware DRM

#488
post #363

i've done a lot of work with Arm TrustZone, OP-TEE, and Arm Trusted Firmware. it's really nice. in Arm, the TEE is user-supplied, not vendor-supplied, so it gives an isolated execution environment for any sensitive code you might want to put in there. hardware peripherals (tzc/spu) allow you to designate certain bus addresses or memory ranges as "secure" during the early firmware initialization, meaning Linux (or wha…

TEE is nice, but it's a pretty different use case all around, and the two are actually quite complementary: TEE is effectively an execution environment below ring 0, together with some hardware isolation as you mention. But by itself, solutions based on it can't hold any trusted key material, so can't be used in attestation contexts. TPMs and other types of secure enclaves or secure elements include secure storage an…

[deleted]

Re: The GPU, not the TPM, is the root of hardware DRM

#489

Earlier quoted context omitted.

This is an FSF level understanding. Android devices are fully open and you can reflash them to whatever OS you want. Some remote servers won't give you service if you do that, but nothing is locking you out of your device . As Android dominates the global market, you already live in that world where most devices are open.

> Android devices are fully open and you can reflash them to whatever OS you want. It doesn't matter. Those devices fail hardware remote attestation. > Some remote servers won't give you service if you do that, but nothing is locking you out of your device. The device's purpose is to be used. If it can't be used without giving up things like banks and private communications, it won't be used. Device is not locked, it…

Meh. I didn't reflash my phone. I didn't root it. I didn't do anything to modify its system files whatsoever.

I just installed KDE Connect, and an open source keyboard. Banking apps refuse to run because of those (because my keyboard might see my keystrokes!!!). They don't even need a failed hardware attestation to refuse you service.

So even if you don't try to modify your device, your device might still end up like half a paperweight. I either can't do banking, or I can't use the functionality I want.

Re: The GPU, not the TPM, is the root of hardware DRM

#490

The author is correct in that media DRM is tied to GPU vendors on the field right now. But hardware backed DRM can be so much more invasive beyond that. I have no doubts the long term goal of MS is to have a Windows version of Play Integrity.[0] So total control over everything that happens on your device. Just to give an example of what could happen if this becomes reality: https://en.m.wikipedia.org/wiki/Web_Enviro…

It's downright cyberpunk. > sites could refuse to serve you if your machine is running any bigcorp unapproved software This needs to be classified as discrimination.

It should be classified as discrimination but the same thing is already reality with mobile apps.
Post reply on HN