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

Heapster: Warn about common forms of permission mistakes #1787

Open
RyanGlScott opened this issue Dec 14, 2022 · 0 comments
Open

Heapster: Warn about common forms of permission mistakes #1787

RyanGlScott opened this issue Dec 14, 2022 · 0 comments
Labels
subsystem: heapster Issues specifically related to memory verification using Heapster type: enhancement Issues describing an improvement to an existing feature or capability usability An issue that impedes efficient understanding and use

Comments

@RyanGlScott
Copy link
Contributor

It is quite easy to accidentally write a Heapster permission type that is syntactically correct but otherwise nonsensical due to programmer mistakes. Here are a couple of common mistakes of this form:

Array permissions with incorrectly sized field shapes

I recently made a mistake when writing a permission of this form:

array(W, 0, <8,*8,fieldsh(8,true))

Can you spot the mistake? Although I indicated that the length is 8 and the stride is 8, I gave it a field shape with 8 bytes. This is wrong as 8 cells * 8 stride yields 64 bytes, so the field shape should actually be fieldsh(64,true).

In cases where the number of cells, stride length, and field shape size are statically known, we should warn whenever the field shape is not large enough to accommodate the size of the array implied by the number of cells and stride length. If Heapster had done this, I would have figured out my mistake sooner.

Disjoint permissions that aren't actually disjoint

I also recently made a mistake when writing a * permission like so:

array(W, 0, <8,*8,fieldsh(64,int64<>)) * array(W, 8, <8,*8,fieldsh(64,int64<>)) 

These permissions are not actually disjoint, as the second array permission's offset (at 8 bytes) overlaps with the first permission, which occupies 64 bytes. I probably meant to give the second permission offset 64 instead. Again, we should warn about these sorts of situations whenever statically possible.

@RyanGlScott RyanGlScott added type: enhancement Issues describing an improvement to an existing feature or capability usability An issue that impedes efficient understanding and use subsystem: heapster Issues specifically related to memory verification using Heapster labels Dec 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
subsystem: heapster Issues specifically related to memory verification using Heapster type: enhancement Issues describing an improvement to an existing feature or capability usability An issue that impedes efficient understanding and use
Projects
None yet
Development

No branches or pull requests

1 participant