4 ms·

Note that third party crates are still allowed to use `unsafe`. Moreover the rust compiler is not infallible and there are some soundness issues that have yet t

Note that third party crates are still allowed to use `unsafe`. Moreover the rust compiler is not infallible and there are some soundness issues that have yet to be fixed.

wffurr 2y ago
Yes; they claim to also address this. I'm not an expert and so can't pass judgement on their claims, but here's what they write (which you would see if you clicked the link and scrolled a bit): >> The intent is that plrust-trusted-pgrx can evolve independently of both pgrx and plrust. There are a few "unsafe" parts of pgrx exposed through plrust-trusted-pgrx, but PL/Rust's ability to block unsafe renders them useless by PL/Rust user functions. >> What about Rust compiler bugs? PL/Rust uses its own rustc driver which enables it to apply custom lints to the user's LANGUAGE plrust function. In general, these lints will fail compilation if the user's code uses certain code idioms or patterns which we know to have "I-Unsound" issues. >> The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions. postgrestd is a specialized Rust compilation target which disallows access to the filesystem and the host operating system. etc.
- SkiFire13 2y ago
  The approach of patching soundness issues seems pretty dangerous to me, since nothing guarantees there won't be more, or that they even perfectly cover the current ones.
  - workingjubilee 2y ago
    The other procedural languages are also not mystically secure from soundness problems, people just fuzz them less.
    - nextaccountic 2y ago
      That's why they should all be sandboxed. Just compile them to wasm and this greatly reduces the surface area of exploits in practice; or, run them in a separate process and sandbox with seccomp (and talk to them with IPC). The former approach actually has less overhead for small components, or at least that's what Firefox devs found out https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Relying on the compiler to do sandboxing is theoretically possible, as done by the Singularity and Midori operating systems from Microsoft (they ran all user programs in kernel mode, without paging, relying only on the compiler to prevent an user from reading memory from another user). But in practice this can't be done with a compiler full of holes like rustc, you would need a compiler that was designed for this from the ground up.

Note that third party crates are still allowed to use `unsafe`. Moreover the rust compiler is not infallible and there are some soundness issues that have yet to be fixed.

wffurr 2y ago

Yes; they claim to also address this. I'm not an expert and so can't pass judgement on their claims, but here's what they write (which you would see if you clicked the link and scrolled a bit): >> The intent is that plrust-trusted-pgrx can evolve independently of both pgrx and plrust. There are a few "unsafe" parts of pgrx exposed through plrust-trusted-pgrx, but PL/Rust's ability to block unsafe renders them useless by PL/Rust user functions. >> What about Rust compiler bugs? PL/Rust uses its own rustc driver which enables it to apply custom lints to the user's LANGUAGE plrust function. In general, these lints will fail compilation if the user's code uses certain code idioms or patterns which we know to have "I-Unsound" issues. >> The "trusted" version of PL/Rust uses a unique fork of Rust's std entitled postgrestd when compiling LANGUAGE plrust user functions. postgrestd is a specialized Rust compilation target which disallows access to the filesystem and the host operating system. etc.

SkiFire13 2y ago
The approach of patching soundness issues seems pretty dangerous to me, since nothing guarantees there won't be more, or that they even perfectly cover the current ones.
- workingjubilee 2y ago
  The other procedural languages are also not mystically secure from soundness problems, people just fuzz them less.
  - nextaccountic 2y ago
    That's why they should all be sandboxed. Just compile them to wasm and this greatly reduces the surface area of exploits in practice; or, run them in a separate process and sandbox with seccomp (and talk to them with IPC). The former approach actually has less overhead for small components, or at least that's what Firefox devs found out https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba... Relying on the compiler to do sandboxing is theoretically possible, as done by the Singularity and Midori operating systems from Microsoft (they ran all user programs in kernel mode, without paging, relying only on the compiler to prevent an user from reading memory from another user). But in practice this can't be done with a compiler full of holes like rustc, you would need a compiler that was designed for this from the ground up.