dart:ffi accessible via mirrors even when --enable-ffi=false

[mdempsky]

It looks like the --enable-ffi flag simply prevents importing "dart:ffi", whereas the library still exists within the VM and is accessible via mirrors. For example:

$ cat x.dart
import "dart:mirrors";

void main() {
  var libs = currentMirrorSystem().libraries;
  var ffi = libs[Uri(scheme: "dart", path: "ffi")];
  print(ffi);
}

$ dart --enable-ffi=false x.dart
LibraryMirror on 'dart.ffi'

It seems like --enable-ffi (and --enable-mirrors) should operate by preventing the VM from constructing and initializing the underlying ffi (or mirrors) Library entirely.

/cc @sjindel-google

[sjindel-google]

I think we should disable the entrypoints from the FFI library into the VM (runtime/lib/ffi.cc, e.g. they could throw an exception) when the FFI is not enabled. The upper (Dart) half of the FFI library is useless if the entrypoints to the VM are disabled.

[mdempsky]

@sjindel-google Agreed that the Dart upper half seems harmless without the native entrypoints lower half, so that sounds reasonable to me too. Out of curiosity though, what do you see as the benefit to that approach vs avoiding creating the library entirely?

[sjindel-google]

IIRC there were some technical issues which made removing the library inconvenient (maybe due to the way loading from Kernel works). However, we should implement both solutions if possible to be safe.

[mdempsky]

It looks like #33594 unintentionally mitigates this problem currently: when using dart:ffi via dart:mirrors, I can't find a way to explicitly supply type arguments, so the type parameters all fall back to their default NativeType, which gets rejected by runtime/lib/ffi.c's CheckIsConcreteNativeType.

[rmacnak-google]

FWIW, the mirrors implementation already has a notion of censored libraries. It should be easy to censor dart:ffi when FFI is disabled in CreateLibraryMirror.