Alan Stokes a0e4296f04 Require unsafe blocks in unsafe functions ... Some hopefully harmless refactoring. Only minor behavioral changes are introduced. Turn on the unsafe_op_in_unsafe_fn lint, treated as an error, for all our low-level code, to ensure that unsafe code is properly highlighted & commented even inside unsafe functions. I've moved the setting from the code to the blueprint in order to make it the default for new code, and reduce clutter. Add unsafe blocks as required to fix all the errors that this surfaced, with appropriate safety comments. I've tried to keep them as small as possible. Slightly to my surprise I removed the unsafe marker from malloc_ (and renamed it in passing); I believe it has no preconditions and is always safe - although doing anything with the returned memory wouldn't be. Bug: 275693559 Test: flash pvmfw, atest MicrodroidTests Change-Id: Ia6f39102caea05c6517bc7500914b7fe7025286c		2023-04-21 12:00:55 +01:00
..
fuzz	[avb][fuzzer] Fuzz pvmfw payload_verify for kernel without footer	2023-01-23 14:12:57 +00:00
src	Require unsafe blocks in unsafe functions	2023-04-21 12:00:55 +01:00
tests	pvmfw: refactor: Expose DICE inputs to main()	2023-02-14 14:51:38 +00:00
Android.bp	Require unsafe blocks in unsafe functions	2023-04-21 12:00:55 +01:00