Certificate mapping does not work in 64-bit mode

[achmelo]

Describe the bug

CEE3204S The system detected a protection exception (System Completion Code=0C4). From compile unit zss/c/certificateService.c at entry point serveMappingService at statement 200 at compile unit offset +000000003B65477A at entry offset +000000000000082A at address 000000003B65477A. Segmentation fault

Steps to Reproduce

1. Start 64-bit version of zssServer
2. request /certificate/x509 with valid JWT and certificate in body

Expected behavior

Screenshots (if needed)

Logs

CEE3DMP.txt

Additional context

[Martin-Zeithaml]

I think, there is a problem, how 31bit addresses are treated, LG loads 64bits:

" LG 15,X'220'(,15) \n" /* CSRTABLE */
" LG 15,X'28'(,15) \n" /* Some RACF Routin Vector */
" LG 15,X'A0'(,15) \n /* IRRSIM00 itself */" 

This loads 31bit address to 64bit register correctly:

" LLGT 15,X'220'(,15) \n" /* CSRTABLE */
" LLGT 15,X'28'(,15) \n" /* Some RACF Routin Vector */
" LLGT 15,X'A0'(,15) \n /* IRRSIM00 itself */" 

[JoeNemo]

Yes. That's the fix that I will put into a PR. You saw the bug too.

[Martin-Zeithaml]

And what about the parameter? This loads the doubleword on address of the parameter list, not the address of parameter list " LG 1,%0 \n" I suppose, there should be LA instead.

[JoeNemo]

I think the LG is fine. We are loading the pointer "RUsermapParamList *userMapCertificateStructure". Which is a 64 bit pointer using a "m" reference. We can verify this tomorrow by printf-ing the parm before the call and causing an Oc1 ( a crappy-but-effective debugging techinque) and after the " LG 1,..." to see that the resulting CEEDUMP has the same value in R1 as our printf to verify.

[JoeNemo]

PR is now in https://github.com/zowe/zss/pull/546

[JoeNemo]

See config example in https://www.ibm.com/docs/en/zos/2.5.0?topic=certificates-examples-adding-digital-certificate-information for testing setup info.

Sample Certificates:

https://github.com/zowe/api-layer/tree/v2.x.x/keystore/clien t_cert

https://github.com/zowe/api-layer/tree/v2.x.x/keystore/localhost

[achmelo]

this issue was resolved