[SMTChecker] Basic support for inline assembly that over-approximates its effects. #10835

blishko · 2021-01-22T10:40:47Z

This PR adds basic support in SMTChecker for the analysis of Inline Assembly blocks.
The basic approach over-approximates the effects of the assembly in the following way:

If any Solidity-level local variable is assigned in the assembly, it is considered as having an unknown value at the end of the assembly block.
If the block modifies storage (e.g., using sstore), all storage variables are considered as having an unknown value at the end of the assembly block.
If the block modifies memory (e.g., using mstore), all memory variables are considered as having an unknown value at the end of the assembly block.
In all other cases, the variables keep their value from just before the assembly block.

This over-approximation at least eliminates false negatives, as were seen in #10619.
It is a first step towards #10596.

blishko · 2021-01-22T10:42:23Z

libsolidity/formal/SMTEncoder.cpp

+//		7737_error,
+//		_inlineAsm.location(),
+//		"Assertion checker does not support inline assembly."
+//	);


Do we want to keep this warning, remove it, or replace with something like "Results might be imprecise because of over-approximation caused by inline assembly"?

We can add the message you suggested when we see we need to reset something, and can omit the message when nothing had to be reset

I have changed the message of the warning.
Since there will always be something over-approximated (if the assembly block is doing anything), I think it is OK to display it every time.

leonardoalt · 2021-01-22T10:56:58Z

test/libsolidity/smtCheckerTests/inline_assembly/assembly.sol

+contract C {
+	function f() internal pure returns (bool) {
+		bool b;
+		assembly { b := 1 } // This assignment is overapproximated at the moment, we don't know value of b after the assembly block


We can support the assignment when the rhs is a literal or a solidity var

As agreed, this is more complicated than it seems on the first glance.
If we continue in this direction, it will be a separate PR.

leonardoalt · 2021-01-22T11:01:49Z

libsolidity/formal/SMTEncoder.cpp

+{
+	m_context.resetVariables([&](VariableDeclaration const& _variable) {
+		return _variable.referenceLocation() == VariableDeclaration::Location::Storage || _variable.isStateVariable();
+	});


I think this is actually the intended behavior of resetStateVariables. So maybe remove resetStateVariables and replace by resetStorageVariables wherever it's used?

As agreed, this will be a separate PR.

libsolidity/formal/SMTEncoder.cpp

blishko · 2021-01-22T18:03:14Z

test/libsolidity/smtCheckerTests/inline_assembly/assembly.sol

+// Warning 7737: (103-122): Inline assembly may cause SMTChecker to produce spurious warnings (false positives).
+// Warning 7737: (103-122): Inline assembly may cause SMTChecker to produce spurious warnings (false positives).
+// Warning 7737: (103-122): Inline assembly may cause SMTChecker to produce spurious warnings (false positives).
+// Warning 7737: (103-122): Inline assembly may cause SMTChecker to produce spurious warnings (false positives).


Seeing this, I think we need a mechanism in SMTChecker to display some warnings only once.

blishko · 2021-01-25T15:32:52Z

@leonardoalt , check if you agree with the error message, or I should revert it back to the original one. As I mentioned, since the inline assembly causes potentially quite a big over-approximations, I would keep displaying the warning.

hrkrshnn

Looks good.

hrkrshnn · 2021-01-26T10:26:14Z

libsolidity/formal/SMTEncoder.cpp

 {
+	struct AssignedExternalsCollector: public yul::ASTWalker
+	{
+		using ExternalReferences = map<yul::Identifier const*, InlineAssemblyAnnotation::ExternalIdentifierInfo>;


This seems to be only used once, so do we really need the using?

Removed the using.

hrkrshnn · 2021-01-26T10:30:20Z

libsolidity/formal/SMTEncoder.cpp

+		{
+			auto const& vars = _assignment.variableNames;
+			for (auto const& identifier: vars)
+				if (auto it = externalReferences.find(&identifier); it != externalReferences.end())


Can you replace this by valueOrNullptr from libsolutil/CommonData.h?

hrkrshnn · 2021-01-26T10:35:15Z

libsolidity/formal/SMTEncoder.cpp

+		}
+	};
+
+	auto assignedVars = AssignedExternalsCollector(_inlineAsm).assignedVars;


I wonder if we really have to write the class AssignedExternalCollector.

There is Assignments in libyul/optimiser/NameCollector.h, which should give you all _assignment.variableNames. Then you could just iterate through the names, without having to write a class. What do you think?

Sorry, I misread your comment initially,Assignments looks useful, thanks for the tip!

Assignments would only give YulString. If you really need Identifier, then you might have to write a walker class. So not sure.

Yeah, Identifiers would be much better, since I am then accessing a map with Identifier * type of keys. I could work around that, but collecting directly Identifiers seems cleaner to me.

hrkrshnn · 2021-01-26T10:36:45Z

libsolidity/formal/SMTEncoder.cpp


+void SMTEncoder::resetMemoryVariables()
+{
+	m_context.resetVariables([&](VariableDeclaration const& _variable) { return _variable.referenceLocation() == VariableDeclaration::Location::Memory; });


A line break?

leonardoalt · 2021-01-26T10:49:38Z

Also please rebase

blishko · 2021-01-26T11:58:39Z

Addressed the comments and rebased.
I am not sure of this should have a changelog entry or not.
It does eliminate some false negatives, but it is still a very over-approximative analysis.

leonardoalt · 2021-01-26T12:08:42Z

I think it should have a Changelog entry at least as a bugfix because it fixes the false negatives

leonardoalt · 2021-01-26T12:09:18Z

Some weird exceptions in Yul tests

blishko · 2021-01-26T12:14:44Z

Some weird exceptions in Yul tests

I don't understand these failings, and they happen in completely unrelated tests.

blishko · 2021-01-26T14:35:29Z

Added a changelog entry and rebased.

hrkrshnn · 2021-01-26T14:46:20Z

test/libsolidity/smtCheckerTests/inline_assembly/assembly2.sol

+	function f() public pure returns (bool) {
+		bool b;
+		int x = 42;
+		assembly { b := 1 }
+		assert(x == 42); // should hold
+		assert(b); // should hold, but fails due to overapproximation
+		return b;


function f() public pure returns (bool) { bool b; int x = 42; assembly { b := 1 } b = 5 assert(x == 42); // should hold assert(b); // should hold return b;

Could you also add a test like this? And a similar one for memory / storage.

@hrkrshnn : Error: Type int_const 5 is not implicitly convertible to expected type bool
Did you mean b = true; instead of b = 5;?

…ng analysis

blishko commented Jan 22, 2021

View reviewed changes

leonardoalt reviewed Jan 22, 2021

View reviewed changes

libsolidity/formal/SMTEncoder.cpp Outdated Show resolved Hide resolved

leonardoalt reviewed Jan 22, 2021

View reviewed changes

libsolidity/formal/SMTEncoder.cpp Outdated Show resolved Hide resolved

leonardoalt reviewed Jan 22, 2021

View reviewed changes

libsolidity/formal/SMTEncoder.cpp Outdated Show resolved Hide resolved

blishko force-pushed the smt-assembly branch from ffdf23c to 3327faf Compare January 22, 2021 11:27

blishko commented Jan 22, 2021

View reviewed changes

blishko force-pushed the smt-assembly branch from e119e4c to bff7798 Compare January 25, 2021 15:20

blishko changed the title ~~Basic support for inline assembly that over-approximates its effects.~~ [SMTChecker] Basic support for inline assembly that over-approximates its effects. Jan 25, 2021

blishko marked this pull request as ready for review January 25, 2021 15:23

blishko requested a review from leonardoalt January 25, 2021 15:31

hrkrshnn reviewed Jan 26, 2021

View reviewed changes

blishko force-pushed the smt-assembly branch from bff7798 to 9147326 Compare January 26, 2021 11:50

blishko force-pushed the smt-assembly branch from 9147326 to bd38345 Compare January 26, 2021 14:24

hrkrshnn reviewed Jan 26, 2021

View reviewed changes

[SMTChecker] Basic support for inline assembly using over-approximati…

484e678

…ng analysis

blishko force-pushed the smt-assembly branch from bd38345 to 484e678 Compare January 26, 2021 15:21

hrkrshnn approved these changes Jan 26, 2021

View reviewed changes

leonardoalt approved these changes Jan 26, 2021

View reviewed changes

leonardoalt merged commit 38d1ec3 into argotorg:develop Jan 26, 2021

leonardoalt mentioned this pull request Jan 26, 2021

[SMTChecker] False negatives and positives because of assembly #10619

Closed

blishko deleted the smt-assembly branch January 27, 2021 07:15

blishko mentioned this pull request Mar 2, 2021

[SMTChecker] Support some inline assembly #10596

Open

[SMTChecker] Basic support for inline assembly that over-approximates its effects. #10835

[SMTChecker] Basic support for inline assembly that over-approximates its effects. #10835

Uh oh!

Conversation

blishko commented Jan 22, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

blishko commented Jan 25, 2021

Uh oh!

hrkrshnn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

leonardoalt commented Jan 26, 2021

Uh oh!

blishko commented Jan 26, 2021

Uh oh!

leonardoalt commented Jan 26, 2021

Uh oh!

leonardoalt commented Jan 26, 2021

Uh oh!

blishko commented Jan 26, 2021

Uh oh!

blishko commented Jan 26, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

blishko commented Jan 22, 2021 •

edited

Loading