-
Notifications
You must be signed in to change notification settings - Fork 183
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Want host flash read over the network #1957
Comments
I don't think there are any security implications to having unauthenticated read access to the QSPI, right? Its contents should be public bitstreams? |
Yes, I believe that's correct. It's a small piece of the output of Helios OS build process (open source), plus that zero page where we write the persistent BSU selection, as I recall? |
I can't think of anything given the existence of public builds. The only thing that I think is worth thinking about is basically whether we want to phrase this as a read of the host image from a virtual slot that will skip over things like the persistent settings hubris uses or the memory-context restore or not. Part of the use of virtual slot is that I think (but am far from certain) for the initial use case I had in mind in an eSPI virtaulization world I'd want to read the virtualized thing. Part of the reason for that is I'm not sure how much metadata or other information would end up in the SPI flash in the future that is derived information or something other than the OS image itself. |
If you have humility access you can use the
qspi -r
orqspi -R
options to read out data from the host qspi. This is probably using theHostFlash.read
operation and it would be nice if we could expose this via control-plane-agent so we could do the equivalents there.The text was updated successfully, but these errors were encountered: