psionic12 added a comment. > This is exactly the problem, filenames specified in *clang* flags are > *supposed* to be read from the VFS. (In practice this probably just means > we'd need to disable this feature in environments where VFS is used)
I don't thinks so, plugins are loaded by using `-fplugin=xxxx.so`, this is a flag being parsed and saved in `FrontendOptions::Plugins`, which is a string vector. As you can see, `xxx.so` is treat as a string, not a file, vfs didn't load it to memory like normal files (for example `main.cpp`) . So I think whether VFS is used or not has nothing to do with plugin loading procedure. > Sure. TL;DR is: clangd flags are configured by the user, user can be fully > responsible for security/stability. > clang flags are configured by the project. If they're bad, we can e.g. give > bad diagnostics, but can't crash or compromise security. > > More detail: > > In the simplest possible case, clangd is configured as follows: > > 1. user downloads clangd binary > 2. user installs an LSP plugin for their editor, and configures the plugin to > use /usr/bin/clangd for C++ files. clangd starts when the editor does > 3. the build system for $PROJECT generates $PROJECT/compile_commands.json > 4. when the user opens $PROJECT/src/foo.cpp in the editor, it notifies > clangd. clangd searches for $PROJECT/compile_commands.json, finds the clang > arguments, and uses them to parse foo.cpp > > *clangd* command-line flags would be added explicitly by the user at step 2. > We can reasonably ask the user to be aware/responsible for security/stability > implications of doing this, including with their particular clangd version. > We can also ask them to run `clangd --check` without the plugin flag to test > whether the plugin is causing a stability problem. > > *clang* command-line flags are added implicitly in step 3. Or they could > simply be checked into the repository - nothing ensures they were generated > locally by the build system. The point is in typical usage they are not > controlled by the user directly, and from a security perspective are not > trusted (as safely opening files from untrusted repos is a reasonable > expectation). So if we're loading plugins based on instructions in clang > command-line flags, clangd bears most of the responsibility for making sure > that's safe and correct (and I don't see a way to do that). I got you point on this, using a clangd command-line flags means users are aware of the the plugin loading. Currently my idea is that if a plugin is listed in the compile_command.json, it will only be loaded if a flag with the same plugin name passed in from clangd command-line. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92155/new/ https://reviews.llvm.org/D92155 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
