AACS errors on Fedora FC 19 X64

[tor123]

Hi

I have Fedora 19 system updated in august. I have installed latest glibc, kernel and nvidia. I am still able to open bluray disc. What packages beside glibc and kernel affects scsi commands.

[nevergonnahappen4me]

I used strace to log the data transmitted via ioctls. I did this while in Fedora and again while in ubuntu. Comparing the results show a number of differences in the data read and written to the BD drive. (I had expected them to be very similar... but maybe I just don't know enough about BluRay drives.) I can also see that eventually in the traces, the 'cmd' values start to differ (I supposed this is an effect of different data values read from the drive).

Anyway, I doesn't make sense to me, so I thought I'd put it here, in case it is helpful to someone else.

Example 1 - Reads: The below is the very first ioctl from the trace.
Fedora: ioctl(9, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 00, 00, 00, 80, 00], mx_sb_len=64, iovec_count=0, dxfer_len=128, timeout=10000, flags=0, data[128]=["\5\200\0052\37\0\0\0TSSTcorpDVDWBD SH-B123L SB04 0331 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"], status=00, masked_status=00, sb[0]

Ubuntu: ioctl(8, SG_IO, {'S', SG_DXFER_FROM_DEV, cmd[6]=[12, 00, 00, 00, 80, 00], mx_sb_len=64, iovec_count=0, dxfer_len=128, timeout=10000, flags=0, data[128]=["\5\200\0052\37\0\0\0TSSTcorpDVDWBD SH-B123L SB04 0331 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\37\267\357\7\210\377\377\0\0\0\0\0\0\0\0"], status=00,

Example 2 - Writes:
Fedora: ioctl(9, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[12]=[a3, 00, 00, 00, 00, 00, 00, 02, 00, 74, 01, 00], mx_sb_len=64, iovec_count=0, dxfer_len=116, timeout=10000, flags=0, data[116]=["\0r\0\0f\334\236~\343$D2\276f~\211\372\rr\271\21F8\204\2\3\0\\\377\377\200\0\0\255\0\0_'\271\37\4~`\302Q\364&-\347N\300a\371&\35\3162T\353s~\336\325:\330N\22\200[\276\355\261,(ZabzR\221)\275\230\370Y\0064\3175\251\202\f\322\23\325\257xk\336H\236\303zu\324\324D\270\253@\222>1qi\351"], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=60, info=0}) = 0

Ubuntu: ioctl(9, SG_IO, {'S', SG_DXFER_TO_DEV, cmd[12]=[a3, 00, 00, 00, 00, 00, 00, 02, 00, 74, 01, 00], mx_sb_len=64, iovec_count=0, dxfer_len=116, timeout=10000, flags=0, data[116]=["\0r\0\0\360\343\262.$k\217\202)P\27\271\37\374\366\322\t\347\205\0\2\3\0\\\377\377\200\0\0\255\0\0_'\271\37\4~`\302Q\364&-\347N\300a\371&\35\3162T\353s~\336\325:\330N\22\200[\276\355\261,(ZabzR\221)\275\230\370Y\0064\3175\251\202\f\322\23\325\257xk\336H\236\303zu\324\324D\270\253@\222>1qi\351"], status=00, masked_status=00, sb[0]=[], host_status=0, driver_status=0, resid=0, duration=60, info=0}) = 0

strace was invoked in the following way:
strace -e ioctl -s 4096 -tt -f -o ~/makemkvcon.strace.txt makemkvcon --debug info disc:0,2,999,12

[cyborg_chippy]

Using Fedora 19 x86_64 with kernel 3.12.5-200.fc19.x86_64 and glibc-2.17-20

Found need to down grade openssl and it's dependences and then recompile makemkv from source to get it working.

yum downgrade openssl openssl-libs openssh-clients openssh openssh-server openssh-askpass openssl-devel python3-libs ruby-libs python3 ruby-irb ruby

Packages Altered:
Downgrade openssh-6.2p2-3.fc19.x86_64 @fedora
Downgraded 6.2p2-7.fc19.x86_64 @updates
Downgrade openssh-askpass-6.2p2-3.fc19.x86_64 @fedora
Downgraded 6.2p2-7.fc19.x86_64 @updates
Downgrade openssh-clients-6.2p2-3.fc19.x86_64 @fedora
Downgraded 6.2p2-7.fc19.x86_64 @updates
Downgrade openssh-server-6.2p2-3.fc19.x86_64 @fedora
Downgraded 6.2p2-7.fc19.x86_64 @updates
Downgrade openssl-1:1.0.1e-4.fc19.x86_64 @fedora
Downgraded 1:1.0.1e-36.fc19.x86_64 @updates
Downgrade openssl-devel-1:1.0.1e-4.fc19.x86_64 @fedora
Downgraded 1:1.0.1e-36.fc19.x86_64 @updates
Downgrade openssl-libs-1:1.0.1e-4.fc19.i686 @fedora
Downgrade openssl-libs-1:1.0.1e-4.fc19.x86_64 @fedora
Downgraded 1:1.0.1e-36.fc19.i686 @updates
Downgraded 1:1.0.1e-36.fc19.x86_64 @updates
Downgrade python3-3.3.2-2.fc19.x86_64 @fedora
Downgraded 3.3.2-8.fc19.x86_64 @updates
Downgrade python3-libs-3.3.2-2.fc19.x86_64 @fedora
Downgraded 3.3.2-8.fc19.x86_64 @updates
Downgrade ruby-2.0.0.195-8.fc19.x86_64 @fedora
Downgraded 2.0.0.353-16.fc19.x86_64 @updates
Downgrade ruby-irb-2.0.0.195-8.fc19.noarch @fedora
Downgraded 2.0.0.353-16.fc19.noarch @updates
Downgrade ruby-libs-2.0.0.195-8.fc19.x86_64 @fedora
Downgraded 2.0.0.353-16.fc19.x86_64 @updates

[mike admin]

Using Fedora 19 x86_64 with kernel 3.12.5-200.fc19.x86_64 and glibc-2.17-20
Found need to down grade openssl and it's dependences and then recompile makemkv from source to get it working.
yum downgrade openssl openssl-libs openssh-clients openssh openssh-server openssh-askpass openssl-devel python3-libs ruby-libs python3 ruby-irb ruby

Ah, the new openssl. I wonder if it is a bug in openssl or in MakeMKV.. Could you please post versions (or preferably source RPMS) of openssl versions that work and that don't ?

[tor123]

HI

I have upload the openssl srpm. Please provide a workaround.

[nevergonnahappen4me]

I was able to reproduce cyborg_chippy's experience: I downgraded openssl to 1:1.0.1e-4.fc19, rebuilt makemkv-oss and was able to open a BD.

Next, I upgraded to the latest openssl (1:1.0.1e-36.fc19), and was still able to open BDs (using the makemkvcon that I had built with the old version of openssl).

I then rebuilt makemkv-oss (with the latest openssl), and was no longer able to open BDs.

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

According to http://www.openssl.org/docs/crypto/EC_GROUP_new.html : "All EC_GROUP_new* functions return a pointer to the newly constructed group, or NULL on error. "

The git repo for F19's openssl package is http://pkgs.fedoraproject.org/cgit/open ... log/?h=f19

[tor123]

I rebuild openssl 1:1.0.1e-4.fc19 for fedora 20 and was able open bluray disc again using makemkv. I later upgraded openssl and makemkv still works.

[MartinKG]

verified, simply took precompiled openssl 1.0.1e-4 version from koji for Fedora20 and installed the 3 needed packages.

Code: Select all

rpm -Uvh --force openssl-1.0.1e-4.fc20.x86_64.rpm openssl-devel-1.0.1e-4.fc20.x86_64.rpm openssl-libs-1.0.1e-4.fc20.x86_64.rpm

recompiled makemkv, works as aspected without problems.

[nevergonnahappen4me]

I spent a little time with 'git bisect' today and found that commit b3551463cafee86a63c60e294f754a8c5cddc37a (aka openssl-1.0.1e-28) is where Fedora 19 became unable to build a functional makemkv-oss. (Though makemkv would continue to function if you had built the package with an earlier version of openssl installed.)

Before commit f19&id=1f19ac14f96ae02be864198a68421f8b1df88be0 (aka openssl-1.0.1e-27), F19 did not include ECC in OpenSSL (build option 'no-ec'). The makemkv-oss package is fine with this and used a bundled version of the OpenSSL ECC code instead.

With commit b3551463cafee86a63c60e294f754a8c5cddc37a, F19 dropped all but the 'Suite B' curves. Admittedly, I know very little about encryption, but I'm guessing that something required by makemkv got dropped.

An easy workaround is to use the command 'CFLAGS=-DOPENSSL_NO_EC ./configure' when building the makemkv-oss package (instead of just './configure'). This will build makemkv-oss using the bundled OpenSSL ECC code instead of trying to use the 'hobbled' version included in F19.

(I believe that the above applies to Fedora 20 as well, but I didn't make any effort to verify that.)

[spear]

Confirmed -- I used rpm2cpio to install openssl-devel-1.0.1e-4.fc19 in a private directory on an F20 system, and then pointed to that directory when compiling makemkv-oss-1.8.7. The result now works. Thanks.

[MartinKG]

Confirmed -- I used rpm2cpio to install openssl-devel-1.0.1e-4.fc19 in a private directory on an F20 system, and then pointed to that directory when compiling makemkv-oss-1.8.7. The result now works. Thanks.

Can you give me a step by step guide, how to do this ?

[nevergonnahappen4me]

I posted more info about this yesterday, but that post hasn't been approved by an admin yet (I think it needs to be approved because it had URLs, so I'm making this post very short and simple).

An easy workaround is to use the command 'CFLAGS=-DOPENSSL_NO_EC ./configure' when building the makemkv-oss package (instead of just './configure'). This will build makemkv-oss using the bundled OpenSSL ECC code, instead of trying to use the 'hobbled' version included in F19/F20.

EDIT: The above worked just fine for me in F19, but does not seem to work in F20.

[tctc1]

Fedora 20 x86_64
Linux e430 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
openssl.x86_64 1:1.0.1e-36.fc20 @updates
ffmpeg.x86_64 2.1.1-1.fc20 @rpmfusion-free

1. After a clean F20 and MakeMKV 1.8.7 install I get the same AACS errors. MakeMKV opens and loads the BD normally but then logs the same AACS errors. (I really didn't expect it to work.)

2. Also tried to use the CFLAGS=-DOPENSSL_NO_EC ./configure with makemkv-oss-1.8.7. It compiles OK but when you open MakeMKV it quickly opens and closes. It doesn't load the BD at all. Weird.

So any news or update on how to get this working? Thanks.

[miracoolix]

Same for me, Segmentation Fault on startup when configuring with "CFLAGS=-DOPENSSL_NO_EC ./configure" (fedora 20)

[crowfax]

Fedora 20, also getting a seg fault with those options.