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

Panic on instructions with non-zero reserved part #737

Merged
merged 9 commits into from
Jun 3, 2024

Conversation

Dentosal
Copy link
Member

@Dentosal Dentosal commented May 22, 2024

Spec PR: FuelLabs/fuel-specs#583

See spec pr for extended description.

Checklist

  • Breaking changes are clearly marked as such in the PR description and changelog
  • New behavior is reflected in tests
  • The specification matches the implemented behavior (linked above)

Before requesting review

  • I have reviewed the code myself
  • I have created follow-up issues caused by this PR and linked them here

@Dentosal Dentosal added breaking A breaking api change fuel-vm Related to the `fuel-vm` crate. fuel-asm Related to the `fuel-asm` crate. labels May 22, 2024
@Dentosal Dentosal self-assigned this May 22, 2024
@Dentosal Dentosal changed the title Panic on opcodes with non-zero reserved part Panic on instructions with non-zero reserved part May 22, 2024
@Dentosal Dentosal requested a review from a team May 22, 2024 20:10
@Dentosal Dentosal marked this pull request as ready for review May 22, 2024 20:11
Comment on lines 57 to 77
fn invalid_reserved_part() {
// Args: 0
Instruction::try_from([Opcode::NOOP as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::NOOP as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");

// Args: 1
Instruction::try_from([Opcode::RET as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::RET as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");

// Args: 2
Instruction::try_from([Opcode::NOT as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::NOT as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");

// Args: 3
Instruction::try_from([Opcode::XOR as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::XOR as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While this behaviour is implemented as a macro, and all opcodes inherit this behaviour, it may be worth testing this for all opcodes. From an opcode-centric perspective, we want to show that each opcode fulfills the specification (regardless of implementation).

Maybe we could have a macro-generated test(s) that tests common behaviours for a given opcode, and maintain a list that invokes this test macro for all opcodes.

But that's up to you - it may be overkill here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me.

bvrooman
bvrooman previously approved these changes May 23, 2024
Comment on lines 63 to 76
// Args: 1
Instruction::try_from([Opcode::RET as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::RET as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");

// Args: 2
Instruction::try_from([Opcode::NOT as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::NOT as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");

// Args: 3
Instruction::try_from([Opcode::XOR as u8, 0, 0, 0]).unwrap();
Instruction::try_from([Opcode::XOR as u8, 0, 0, 1])
.expect_err("Reserved part is nonzero");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see where are we using arg 2 and arg 3=)

fuel-asm/src/macros.rs Show resolved Hide resolved
Copy link
Collaborator

@xgreenx xgreenx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's discuss first regarding suggestion to move the check to unpack level=)

xgreenx added a commit to FuelLabs/fuel-specs that referenced this pull request May 27, 2024
…#583)

VM PR: FuelLabs/fuel-vm#737

What is says on the tin. This is a small but breaking change. It's
unlikely to cause any breakage, as no Sway code or code constructed
using the fuel-asm helper functions is affected.

This change is originating from an audit report that pointed out the
likely unintentional behavior of the unused part of instruction is
ignored.

### Before requesting review
- [x] I have reviewed the code myself

Co-authored-by: Green Baneling <XgreenX9999@gmail.com>
xgreenx added 2 commits June 1, 2024 00:10
…f packed.

Added tests to verify behaviour for the unreserved parts.
xgreenx
xgreenx previously approved these changes Jun 1, 2024
xgreenx
xgreenx previously approved these changes Jun 1, 2024
#[cfg_attr(feature = "typescript", wasm_bindgen::prelude::wasm_bindgen)]
pub struct RegId(u8);

/// Represents a 6-bit immediate value, guaranteed to be masked by construction.
#[derive(Clone, Copy, Debug, Eq, Hash, Ord, PartialEq, PartialOrd)]
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The derived Deserialize impl allows constructing invalid values.

@Dentosal Dentosal added this pull request to the merge queue Jun 3, 2024
Merged via the queue into master with commit dd926e4 Jun 3, 2024
38 checks passed
@Dentosal Dentosal deleted the dento/opcode-reserved-part branch June 3, 2024 07:32
@xgreenx xgreenx mentioned this pull request Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking A breaking api change fuel-asm Related to the `fuel-asm` crate. fuel-vm Related to the `fuel-vm` crate.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants