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

Implement restrictions on variables at external scope #40

Open
secure-sw-dev-bot opened this issue Jan 16, 2022 · 1 comment
Open

Implement restrictions on variables at external scope #40

secure-sw-dev-bot opened this issue Jan 16, 2022 · 1 comment
Labels

Comments

@secure-sw-dev-bot
Copy link

This issue was copied from checkedc/checkedc-clang#40


Section 3.2 describes restrictions on variables at external scope that have bounds declarations. These restrictions need to be implemented.

@secure-sw-dev-bot
Copy link
Author

Comment from @mattmccutchen-cci:

Note: What was section 3.2 at the time this issue was filed (in this revision) is now section 3.6.4 (in this revision).

Section 3.6.4 says: "All places in a program that may write to a variable with external scope also must have the same view of the bounds declarations involving that variable. This allows static checking to ensure that bounds declarations remain valid." However, the rule proposed later in the section is not sufficient to guarantee that property across translation units. Here's an example based on the one in section 3.6.4:

shared.h:

extern int size;
extern void update_size(int i);

update_size.c:

#pragma CHECKED_SCOPE on

#include "shared.h"

void update_size(int i) {
  size = i;
}

main.c:

#pragma CHECKED_SCOPE on

#include "shared.h"

int size;
_Array_ptr<int> ap : count(size);
int arr _Checked[10];

int main(void) {
  size = 10;
  ap = arr;
  update_size(100000000);
  ap[99999999] = 0xbad;  // SIGSEGV
  return 0;
}

Is this yet another problem the programmer is obliged to check for manually if they want a guarantee of spatial memory safety, or do we want to try to address it in the language?

If the latter, we'd somehow need to know when compiling update_size.c that size is used in the bounds declaration of a variable that is not visible in that translation unit. One simple approach would be to require that the first declaration of size give a list of the names of all global variables (if any) whose bounds declarations may refer to size. This might look something like the following in shared.h:

extern int size _Used_by_bounds(ap);
extern void update_size(int i);

Then the compiler would reject the assignment in update_size because it doesn't know whether the assignment invalidates the bounds of ap. If the _Used_by_bounds(ap) is omitted, then the bounds declaration of ap in main.c would be rejected.

As this proposal stands, an attempt to take a size variable declared in a header of a plain-C library and re-declare it with _Used_by_bounds would be rejected, because the risk that some translation unit that includes the first declaration and not the second could invalidate the bounds is exactly what we are trying to prevent. If needed for interoperability, we could have a way to bypass that restriction and make clear that the programmer takes responsibility for the risk of unsoundness. (Maybe that construct would not be allowed in a checked scope?)

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

No branches or pull requests

1 participant