Skip to content
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

Security Levels for Initialised Memory Sections #82

Open
l-kent opened this issue Sep 22, 2023 · 1 comment
Open

Security Levels for Initialised Memory Sections #82

l-kent opened this issue Sep 22, 2023 · 1 comment

Comments

@l-kent
Copy link
Contributor

l-kent commented Sep 22, 2023

Currently the security level of the initialised memory sections put in the precondition of main() are not specified. We should assume them to be low for now, and either add axioms for them or add this information to the precondition of main(). We should also make care to exclude any global variables in the .data section from this assumption, as the security levels of those should be specified by the user.

Whether to use axioms or put this information in the precondition of main relates to #81 - it would only really be safe to add axioms for them if they are never written to by the program.

The axioms would look like axiom gamma_load8(mem, _address_); for each byte of the initialised memory that we want to specify as low.

Future work would include a way for the user to manually specify security levels for other parts of the initial memory, but that isn't relevant for now and should wait until a wider rework of the specifications has taken place.

@l-kent l-kent assigned l-kent and unassigned l-kent Oct 9, 2023
@l-kent
Copy link
Contributor Author

l-kent commented Oct 9, 2023

Since Boogie doesn't support axioms referencing mutable global variables (I forgot), it would make sense to instead insert these as free requires/ensures clauses for every procedure, similar to the approach taken in #92.

The most relevant examples are arrays_simple/gcc and arrays_simple/gcc_pic, but these pose an additional problem - the address of the stack_chk_guard symbol isn't currently initialised at all (because it can't be), so we probably want to additionally make the offsets in .rela.dyn of type R_AARCH64_GLOB_DAT return values that are low, as well as the memory sections we already initialise from #92.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant