Repository navigation
Fix demux_matrix freeing memory inside function blocks - #1803
Merged
Merged
Conversation
Member
|
Thank you |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I found this when a
RecursiveORAMof 1,024 entries returned wrong values for most of the entries I read back.oram_tutorialis affected too: it prints0instead of1with every protocol I tried.demux_matrixfrees its temporary matricesaandbbefore it returns, so that the compiler can give their memory to arrays and variables created later.LinearORAMcalls it in its method blocks_read,_writeand_access, whose code is generated at the first access and then called by every access. In these blocks, freeingaandbis wrong: their memory is freed at the first access, but every later access still writesaandbto it, and so overwrites any array or variable placed in it in the meantime. The contents of theLinearORAMare not affected, because they are allocated before its first access. So the bug only shows in memory allocated after the first access to aLinearORAM, and only if that memory is still needed after a later access. For example, withScripts/compile-run.py -E ring,-E sy-rep-ring,-E rep-field,-E semi2kor-E semi, the following prints[1, 0, 0, 0]instead of[5, 5, 5, 5]:Here,
xgets the memory ofb, which the second access toooverwrites.The same happens in the test where I found the bug, which uses a
RecursiveORAMof 1,024 entries directly. Its constructor first writes to the position map, which is aLinearORAM, to initialise it, and then allocatesread_value,read_non_emptyandstate, which get the memory ofa. Every access to theRecursiveORAMupdates the position map, and every update writesainto these variables. With the same five protocols, when I write 128 of its entries, overwrite a third of them and read them back, most of the values are wrong.Fix
demux_matrixnow freesaandbonly outside function blocks.Testing
With the fix, the snippet prints
[5, 5, 5, 5],oram_tutorialprints1, and theRecursiveORAMof 1,024 entries reads back correctly, with the five protocols. Rounds and communication are unchanged.The fix changes the bytecode only where
demux_matrixis called inside a function block, for example indijkstra_example,gale-shapley_tutorial,gc_oramandoram_tutorial.dijkstra_exampleandgale-shapley_tutorialprint the same output with the fix.