View Single Post
Old November 14th, 2018   #3
shawn
Junior Member
 
Join Date: Nov 2018
Location: Oakland, CA, USA
Posts: 19
Default

Thanks for your quick response, Scott.

My WRITE_PROTECT code is already only at the top of the part that examines SET messages (per section 3.7 of E1.37-1, where it says that LOCK plus WRITE_PROTECT is for SET_COMMAND).

I think that I'll return NR_WRITE_PROTECT before checking message format and data, but I'm still considering whether to return NR_WRITE_PROTECT before checking for UNKNOWN_PID and before UNSUPPORTED_COMMAND_CLASS.

Here's why I'm debating this. On trusted systems and setups, I don't see a problem broadcasting information about what is and isn't supported on the device. However, if someone took the trouble to lock things down (even with a minimal capability like E1.37-1's LOCK), then is it more security conscious to not leak this information? Maybe this is overthinking it too much on what isn't really a secure system anyway.

So then the other consideration is what would be "nice to have" from the controller's point of view? WRITE_PROTECT on all SET commands or WRITE_PROTECT on only supported SET commands?
shawn is offline   Reply With Quote