You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some memory in our VM is initialised according to what's in the ELF. Some of it is initialised according to the contents of various tapes.
But the vast majority falls outside of these two cases.
Early on we made the design decision that all such memory should be zero initialized, because that's the least surprising behaviour for our users (eg it's also what Linux does for security reasons, when the kernel hands memory to your program), and would cause the least harm, if people misunderstand the convention.
The two reasonable alternatives we considered were:
Fail the program on reading uninitialised memory. This is simplest to implement for us, but can be very frustrating for users.
Allow the prover to provide arbitrary values. This would be a neat way to inject arbitrary values into the program, ie to replace the private io tape. But it would really trip up the unwary, and could lead to huge security problems in guest programs.
This issue concerns 'Mozak memory', ie the memory regions where we load our tapes. When we added the tape-via-pre-initialised-memory mechanism, there was some miscommunication and we accidentally stopped the zero-initialisation of those regions.
So let's fix that to close this issue.
As for testing: we can write a guest program that reads arbitrary random memory addresses (using proptest).
The text was updated successfully, but these errors were encountered:
matthiasgoergens
changed the title
vm(trace-generation): ensure and test that all memory reads are zero initialized
vm(trace-generation): ensure and test that memory reads are zero initialized
Mar 1, 2024
Some memory in our VM is initialised according to what's in the ELF. Some of it is initialised according to the contents of various tapes.
But the vast majority falls outside of these two cases.
Early on we made the design decision that all such memory should be zero initialized, because that's the least surprising behaviour for our users (eg it's also what Linux does for security reasons, when the kernel hands memory to your program), and would cause the least harm, if people misunderstand the convention.
The two reasonable alternatives we considered were:
This issue concerns 'Mozak memory', ie the memory regions where we load our tapes. When we added the tape-via-pre-initialised-memory mechanism, there was some miscommunication and we accidentally stopped the zero-initialisation of those regions.
So let's fix that to close this issue.
As for testing: we can write a guest program that reads arbitrary random memory addresses (using
proptest
).The text was updated successfully, but these errors were encountered: