Hello,

We are now getting to the stage where we need to consider what protection mechanisms we want (or need) to employ with 
our system that will within the next few months (hopefully) enter production phase. I am very aware of the unique 
features provided by QNX to lock down the system (such as encrypted IFS, read-only IFS, procmgr abilities, etc). In our 
case we have an additional "security" mechanism and that is on our Xilinx (ARM64le) system the SD card is read-only. 
Despite our attempts to rectify it using guidance provided in the ZCU-104 release notes (another story). FYI, only the 
ZCU-102 allows us to write to SDMMC. Also, we are intending to use an Enclustra XU1 Mercury MP-SoC  which is basically 
identical to the Xilinx products. (We need to use these expensive products because we have rather hefty FPGA 
requirements).

I am actually not too upset about this as ordinarily I would be happy for no writable mass storage device to be employed
 (by the production system). Except for one case scenario.

What is a generally accepted approach taken to lock down modern QNX systems that ordinarily require no write to non-
volatile storage capability except when updating "firmware"?

While (as I said) I would ordinarily be content with a read-only SD based file system, for this purpose I think we 
really need it to be writable in certain but controlled circumstances (such as system updates). But the intent would be 
for it to be normally read-only. As a result we need to get these SD cards writable and we're working on that. But I am 
concerned that by doing so we open up a possible "back door".

We have tried to get eMMC working but like the SDMMC we can't write to it. We ran into all sorts of problems actually so
 we dropped that idea.

Should we be looking at employing QSPI (FLASH)? If so, how easy is it to provide a procedure for customers to use in 
order to update system firmware/software (whatever)? I'm not sure if providing JTAG capability and instructions would be
 a good idea. I haven't tried using QSPI before and am not sure how the IPL gets to find it and run the IFS from it. As 
I understand things there is no need to copy the IFS into memory - just the startup code.

So what is the recommended approach in this situation? If necessary, if QSPI is deemed to be the way forward we can look
 at that (it has certain attractions as at least it can't be removed for nefarious purposes)! The IPL provided in the 
BSP makes it easy to boot from SDMMC but I'm not sure what would need to be done to run from QSPI.

Thanks, and Cheers,

Geoff.