[Cbe-oss-dev] Playstation 3 BD-ROM access and LV1_DENIED_BY_POLICY

Nicholas A. Bellinger nab at kernel.org
Fri Aug 3 02:29:08 EST 2007


On Thu, 2007-08-02 at 08:33 -0700, Geoff Levand wrote:
> Nicholas A. Bellinger wrote:
> 
> > 1) Why has this changed after working for me for months, and through 30+
> > different commerical BD-ROMs under 2.6.16, only to now be denied with
> > *BOTH* kernels with LV1_DENIED_BY_POLICY after a single boot into
> > 2.6.23-rc1..?
> 
> 
> It seems strange that it didn't work when you reverted to the 2.6.16 kernel.
> My guess, and only a guess, is that your method was in error, or that, as
> Ralf suggested, the drive has now changed its behavior, perhaps because with
> the new Linux driver there was an interaction with the drive such that entered
> a new state, whereas with the old driver there was not such an interaction and
> the drive never entered the state.
> 

The problem is very specific from my point of view.  Where I was once
able to issue the ATAPI command descriptor block (CDB) REPORT_KEY
through the hypervisor under GuestOS, I am no longer able to do so on my
machine.

Note that REPORT_KEY is the first ATAPI CDB that is generated by the
software client in order to begin the AACS process.  In order to futher
break down the CDB in question...:

ps3rom sb_03: ps3rom_atapi_request:175: send ATAPI command 0x43
sr 0:0:0:0: CDB: cdb[0]=0xa4, sa=0x0: a4 00 00 00 00 00 00 00 00 08 08
00

http://www.t10.org/ftp/t10/drafts/mmc5/mmc5r04.pdf

cdb[10], which in this case is 0x08, defines that the 'Key Format' field
equals 'RPCState' and 'Key Class' equals 0 as defined in section
6.29.3.1.7.  As the data payload contained in the reponse of this
particular CDB contains things like the region code, RPC Scheme field,
et al, if this CDB cannot be completed successfully to the drive, the
software player will not be able to continue.

So just to be clear, I have been able to previously issue this exact
same 12 byte ATAPI CDB, under 2.6.16, since I was first able to move BD
packets over the network some months ago.  I am still able to successful
watch commerical BD-ROMs with an external BD drive.  And I am sure that
if I was to located another PS3 today, and put the original software
setup that I had on the console, I would be able to issue this CDB
through the hypervisor.

> 
> > 2) What has to happen in order for me to continue to watch commerical
> > BD-ROM content from PS3-Linux console over iSCSI..?  At this point, the
> > ability to issue these ATAPI commands from a remote machine is very
> > important to me personally, that I have been debating getting another
> > console and sticking with 2.6.16 permanently.  Or at least until this
> > newly added restriction can be removed.
> 
> 
> I think we need to understand what the exact cause is before we can discuss
> what, if anything, can be done to resolve it.  I will make some inquiries,
> but that will take some time.
> 
> 

This I can appericate, and I have nothing but time and resources on my
side to get this resolved.  Please let me know what specifics you need
from me on the technical side in order to move forward.

> > 3) What can I do the prove that they are legitimate purposes (other than
> > my screen captures) for re-allowing the ability to issue these commands
> > under Linux..?
> 
>  
> As above, before understanding the exact cause, and hence, a possible plan
> of resolution, I don't think there is any reason to do so.
> 

Thanks for your response Geoff.

--nab




More information about the cbe-oss-dev mailing list