Atmosphere: YouTube app causes errors related to HDCP when docking

[shutterbug2000]

Bug Report

What's the issue you encountered?

Whenever the Switch is docked, the console either will crash (occurs for me when not holding the R button while booting YouTube), or (when holding the R button) the console will give a message stating that Protected content cannot be displayed.

How can the issue be reproduced?

Simply open the YouTube app while the console is docked, or dock it after opening the app while undocked

Crash report?

(If a crash report was created under /atmosphere/crash_reports/, please upload it to
gist and paste the link here.)

Environment?

• What bootloader (fusee, hekate, etc) was Atmosphère launched by: fusee
• Official release or unofficial build: Official
• Do you have additional kips you're loading: No
• Additional info about your environment:

Additional context?

[SciresM]

Some debugging happened in ReSwitched #switch-hacking-meta.

It turns out that this issue is not just an Atmosphere issue, it's an all-current-cfw-bootloaders issue. Hekate + stock also has this occur.

Current best speculation is that cfw bootloaders are fucking up the TSEC in some way, since it's responsible for HDCP at runtime. Also possible is that they're not configuring the GPU or DISPLAY right, but I consider those less likely.

[CTCaer]

Can a test be conducted without https://github.com/Atmosphere-NX/Atmosphere/blob/164fb96da01429a7676e5abd260debf19ef200bf/fusee/fusee-primary/src/hwinit.c#L297

(gpu/display should be out of question, as they are configured/reconfigured later on)

[SciresM]

@CTCaer Oh wow, good catch there. fusee definitely should not be touching the carveouts, especially on >= 4.0.0 where exosphere expects to be writing configuration to the gpu ucode in dram before it gets protected...

[SciresM]

I think a better test would be to make https://github.com/Atmosphere-NX/Atmosphere/blob/164fb96da01429a7676e5abd260debf19ef200bf/fusee/fusee-secondary/src/nxboot_iram.c#L44

firmware-dependent (only locking the GPU UCODE carveout if firmware < 4.0.0... (or not at all, exosphere does it unconditionally anyway))

[SciresM]

@CTCaer Tested with both of those lines commented out, still causes fatal error :/

[CTCaer]

Well one reason of the 2 I split the carveout into 2 pieces was that. But I never added it to the fw check because the compatibility never broke.

the generalized carveouts (lp0) also come to mind but if I remember, these didn't change in 6.x.x..
I'll check them when I have time.

[hexkyz]

Turns out we missed this change in TrustZone:
[5.0.0] MAKE_MC_REG(MC_SECURITY_CARVEOUT2_CLIENT_ACCESS2) = 0x3000000;
[6.0.0] MAKE_MC_REG(MC_SECURITY_CARVEOUT2_CLIENT_ACCESS2) = 0x3100000;

The extra bit being set grants TSEC read access to the GPU UCODE carveout, which explains why HDCP would fail (when docked, a special method is sent to the TSEC for streaming key data and this probably requires access to the carveout).
There may be more to it, but as far as I can tell this should be the main issue.

[fennectech]

Ive compiled with the appropiate change in mc.c and replaced exosphere.bin but ive seen no change in the issue.

(the change i made was on line 50 and 90
changed the lines to contain this
carveout->flags_2 = 0x3100000;

[hexkyz]

@fennectech Thanks a lot for testing! Line 91 doesn't need the change, but it won't affect the final result anyway. Since it still fails, this means there must be more carveout changes we've missed.

[CTCaer]

@fennectech
Did you commented out the 2 functions in fusee 1st and 2nd also?
The bit1 in the CFG0 is set on fusee and that locks any write access there.

(MC(MC_SECURITY_CARVEOUT2_CFG0) = 0x440167C; that's the value for not locking it)

[hexkyz]

As @CTCaer pointed out, fusee was locking the GPU carveouts and preventing any further writes.
I've updated fusee to comply with the 4.0.0+ changes that moved all MC carveout configuration into the Secure Monitor.

[fennectech]

I’m using hekate but i recompiled hekate with the needed changes too. Ive even tried enabling fulsvcperm

[SciresM]

@fennectech For testing atmosphere bugs, please use fusee.

[fennectech]

Okay. I will try it tonight.

[CTCaer]

Btw, what fw version you both have? Because I had reports with fusee and hekate working on 6.1.0.

Also have in mind that the carveouts are locked and disabled (can't remember which) in RCM (VOL UP + HOME).
Only with AutoRCM (PWR) they are fully set.

[SciresM]

@CTCaer I'm not actually testing, myself.

Also, is there some way to fix the above? It seems...bad that AutoRCM vs RCM could result in users experiencing different functionality once in HOS.

[CTCaer]

@SciresM Same. I don't have 6.x and neither youtube.
The version question went to OP and fennec and the carveouts bit to @hexkyz

EDIT:
But it's also a good idea for the testing to be conducted in both modes.

[fennectech]

I’m on 6.1.0 with autorcm. It works exactly the same as 6.0.0. And 6.0.1

[CTCaer]

I c. Can you try the following:

Power off completely while you are connected to the device that injects.
Then use the combo: VOL UP + HOME (jig) + PWR.
This will enter normal RCM and try again.

[fennectech]

OI. Thats annoying. I dont have any good jigs. Ill get some alfoil and give it a try.

[CTCaer]

Pff. Don't then.

It's a risk to fry your device.

Someone else can test. It's not important to find what's happening right now.

[fennectech]

Ive already got my foil jig made up. The only risk is burning fuses (wich is fine with me)

[CTCaer]

You don't risk of burning fuses because the BCT is still corrupted (autorcm enabled).
Also with tinfoil you can touch the voltage pin. I believe you can understand what this means.
So don't do it.

[fennectech]

I know the risk. I had already gotten it stuck in and booted regular RCM.
Let’s test

[fennectech]

No dice. Normal RCM (with autorcm disabled) still experiences the issue with my alterations and hekate. Ill make that altered fusee and try

[SciresM]

@fennectech Just use master, if you're going to test. It should include the fixes, in theory.

This includes using the fusee-primary changes made in master.

[CTCaer]

Don't make it, just update your local copy. Hexkyz already committed the changes needed.

EDIT:
Ninja'd

[fennectech]

okay :D im compiling now.
ive gotten good at making these foil jigs.

[fennectech]

Is hekates chainloader okay?

[CTCaer]

No. It will set the carveouts at boot. You need to inject fusee as is

[fennectech]

okay Ill reboot into windows.

[CTCaer]

Actually, I forgot. I've put that particular carveout to HOS launch so it will be skipped.
Doesn't matter though. Use it vanilla. We want to minimize the factors

[fennectech]

Booting now.

This is with vanilla booted via tegrarcmgui with the fusee-primary and fusee-secondary produced when running make dist.

[fennectech]

I will try full stock. Full stock works fine.

[fennectech]

Any solution yet?

[SciresM]

@fennectech Try latest master, fusee-primary, etc. @hexkyz pushed another bugfix to exosphere.

[fennectech]

@SciresM Stil no fix with normal RCM with freshly made fusee-primary/secondary

[fennectech]

Is autorcm still a problem?

[hexkyz]

@fennectech Could you please try again with the latest fixes?

[fennectech]

Currently compiling.

[fennectech]

And THATS A WRAP HDCP WORKS!
I have tried autorcm only And that works.

Could you please let the guys over at hekate know what to change to fix it?

[hexkyz]

"Could you please let the guys over at hekate know what to change to fix it?" -> Of course.

Closing this issue now.