btashton commented on issue #3011: URL: https://github.com/apache/incubator-nuttx/issues/3011#issuecomment-797621741
> I would suggest we may need to disable "mw"-like commands as @patacongo mentioned at default because it does not look like such useful.... > Also, I have the following opinions. > > 1. I think "NSH access permission" != "firmware extraction permission (or allowing firmware extraction)". > If there was no "mw" command, firmware extraction is not possible. > Meanwhile @btashton said that STM32F4's readout protection is very broken (I assume you mean we can disable STM32F4's readout **w/o any problem**.). > But, I remember there is no practical way to do that.... Sorry for my ignorance. Could you tell me how to do that? > Even if that is really very broken, that does not mean we should not protect against this vulnerability. > Because this can happen on other "unbroken" boards, I think we should make it more secure. > > Again, NSH access itself is not firmware extraction permission. Additionally, if applications running on NSH are properly implemented, NSH may not cause unexpected security issues such firmware extraction (I note that vendor deployed readout protection to protect their firmware contents). > Sure here is a recent write-up on how this was done to trivially bypass all the protection. My point here is more of a philosophical one that firmware protection is most hardware ranges from very broken to hard to break. And very little requires going to decaping chips. Some security focused chips fall much closer to the very hard end of the spectrum. So the focus should be more on preventing unauthorized firmware than trying to hide IP. https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/ > 2. Second, @patacongo mentioned PROTECTED mode. But, I think NuttX is open source. Therefore, I guess what the vendors really protect is their **"application code from the firmware extraction"**. In that case, I guess "mw" commands work for "application code". If my understanding is incorrect, please let me know. That's good to learn. If you are operating in flat mode there are so many possibilities. If they had the ability to load and elf you could simply copy the mw or mr binaries over and execute them. Some devices have block devices and you could simply use cat or dd to write out that device. This is why for any device it is important to be able to understand your security posture and make sure you evaluate it. Running ? in the nsh shell and making sure you know what is there is a low bar. This all said while I don't buy the security argument here, I also don't feel opposed to making these non default, I'm just not going to submit the PR. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
