Description of problem: I am unable top open a bluray disc with makemkv which worked with the same external bluray driver in Ubuntu 13.10 in linux 3.11.10-200.fc19.x86_64 Version-Release number of selected component (if applicable): How reproducible: each time Steps to Reproduce: 1. open disc in makemvk 1.8.7 2. 3. Actual results: should read, worked before Expected results: should read. Additional info: eAEU206 usb bluray disk [216777.079469] VFS: busy inodes on changed media or resized disk sr2 DEBUG: Code 0 at eGPcy&II ^zh,7!}F{:121264303 DEBUG: Code 1 at eGPcy&II ^zh,7!}F{:121262394 DEBUG: Code 0 at eGPcy&II ^zh,7!}F{:121263843 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:2' DEBUG: Code 0 at eGPcy&II ^zh,7!}F{:121264303
00:00.0 Host bridge: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port (rev 13) 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 1 (rev 13) 00:02.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 2 (rev 13) 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 3 (rev 13) 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI Express Root Port 7 (rev 13) 00:14.0 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub System Management Registers (rev 13) 00:14.1 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers (rev 13) 00:14.2 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub Control Status and RAS Registers (rev 13) 00:14.3 PIC: Intel Corporation 7500/5520/5500/X58 I/O Hub Throttle Registers (rev 13) 00:1a.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #4 00:1a.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #5 00:1a.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #6 00:1a.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #2 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller 00:1c.0 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 1 00:1c.2 PCI bridge: Intel Corporation 82801JI (ICH10 Family) PCI Express Root Port 3 00:1d.0 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #1 00:1d.1 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #2 00:1d.2 USB controller: Intel Corporation 82801JI (ICH10 Family) USB UHCI Controller #3 00:1d.7 USB controller: Intel Corporation 82801JI (ICH10 Family) USB2 EHCI Controller #1 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 90) 00:1f.0 ISA bridge: Intel Corporation 82801JIR (ICH10R) LPC Interface Controller 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller 00:1f.3 SMBus: Intel Corporation 82801JI (ICH10 Family) SMBus Controller 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 11) 02:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03) 03:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 770] (rev a1) 03:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1) 05:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 12) 07:02.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller (rev c0) ff:00.0 Host bridge: Intel Corporation Xeon 5500/Core i7 QuickPath Architecture Generic Non-Core Registers (rev 05) ff:00.1 Host bridge: Intel Corporation Xeon 5500/Core i7 QuickPath Architecture System Address Decoder (rev 05) ff:02.0 Host bridge: Intel Corporation Xeon 5500/Core i7 QPI Link 0 (rev 05) ff:02.1 Host bridge: Intel Corporation Xeon 5500/Core i7 QPI Physical 0 (rev 05) ff:03.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller (rev 05) ff:03.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Target Address Decoder (rev 05) ff:03.4 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Test Registers (rev 05) ff:04.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Control Registers (rev 05) ff:04.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Address Registers (rev 05) ff:04.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Rank Registers (rev 05) ff:04.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 0 Thermal Control Registers (rev 05) ff:05.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Control Registers (rev 05) ff:05.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Address Registers (rev 05) ff:05.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Rank Registers (rev 05) ff:05.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 1 Thermal Control Registers (rev 05) ff:06.0 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Control Registers (rev 05) ff:06.1 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Address Registers (rev 05) ff:06.2 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Rank Registers (rev 05) ff:06.3 Host bridge: Intel Corporation Xeon 5500/Core i7 Integrated Memory Controller Channel 2 Thermal Control Registers (rev 05)
bluray driver worked with Ubuntu 13.10 on another pc. I only check if I were able to mount the disc.
I mount a bluray disc with video.
Apparently the kernel in Fedora 19 has an unknown bug that filters or damages raw SCSI commands sent by MakeMKV to the drive. As a result MakeMKV fails to open any blu-ray disc with an AACS error. So far the error was only reported on x64 kernel. The cause of the bug is not known, and there is no workaround short of using Ubuntu live cd or inside the VM. If you encounter AACS failures under linux, and are using the latest version of MakeMKV, please report your distro and kernel version in this thread. http://www.makemkv.com/forum2/viewtopic.php?f=3&t=7370
Still present on latest kernel. kernel-3.12.5-302.fc20.x86_64
It turn out that this is not a kernel bug, but rather a problem with openssl makemkv interation. From Makemkv forum. Using ltrace shows that the first 580 calls from libmakemkv.so.1 to libcrypto.so.10 are exactly the same between to two builds (satisfying!). Call #581 starts the differences: 1:1.0.1e-4.fc19 - libmakemkv.so.1->CRYPTO_malloc(232, 0x7f7930cf4175, 93, 0x7f792802b440) = 0x7f792805eab0 1:1.0.1e-36.fc19 - libmakemkv.so.1->EC_GROUP_new_curve_GFp(0x7f35b4059340, 0x7f35b40094f0, 0x7f35b40593e0, 0x7f35b4059390) = 0
The OpenSSL in Fedora does not support all EC curves due to legal reasons. libmakemkv must cope with that gracefully.
I have managed to get an explanation from makemkv upstream: This is not because of NIST curves. The openssl in fedora has an unique fips patch. The library can be in two modes - fips and non-fips. Several "insecure" ciphers are always disabled in fips mode. On fedora default is non-fips, and even then application can switch to non-fips mode, in order to use "old" ciphers. Now, the bug - most places where fips check is made, it is made properly - inside #ifdef OPENSSL_FIPS and by calling "is fips enabled" function. However for EC, whoever was making a patch made an unconditional decision: all EC curves smaller than 256 bits are always disabled if OPENSSL_FIPS is #defined. AACS uses 192-bit curves. The patch is fedora-specific and there is no way to detect the condition during configure/compile time. The proper fix is to allow any curve order in non-fips mode. Starting with next version MakeMKV will automatically use its own EC code if compiled on fedora. Are 192-bit curves also affected by the legal reasons you mention?
Yes, they are affected. This is not related to FIPS. Unfortunately they are right that this cannot be detected during compile time and has to be handled in run time.