On Mon, 20 Oct 2025, Piyush Raj wrote: > Hi Hans, > > On 19/10/25 07:46, Hans-Peter Nilsson wrote: > > On Mon, 13 Oct 2025, Piyush Raj wrote: > > > > > This patch adds the bpf-vmtest-tool subdirectory under contrib which tests > > > BPF programs under a live kernel using a QEMU VM. It automatically > > > builds the specified kernel version with eBPF support enabled > > > and stores it under "~/.bpf-vmtest-tool", which is reused for future > > > invocations. > > > > It wasn't immediately clear to be if it happens as written > > above, but it sounds like this tool may "helpfully" write to > > ~/.bpf-vmtest-tool. Could you please make sure that the > > invocation of this tool, as invoked for testing gcc, does *not* > > write outside the gcc build directory, specifically not to the > > user's home directory? > > > > That'd be quite rude. It'd be better to write there only when > > specifically requested (not in any regtest session) and error > > out if that directory, or one specified by some option, doesn't > > exist. > > > > brgds, H-P > > PS. otherwise nice hack > > This tool is only invoked by runtest if the bpf board is explicitly requested. > > For example: > make check-gcc RUNTESTFLAGS="--target_board=bpf bpf-torture.exp"
Yes, that's a prerequisite, but... > In a normal "make check-gcc" invocation, the tool will not be executed, so the > user?s home directory will not be accessed. > > Considering this, do you see any other cases where the tool might be invoked > unintentionally ? ...design-wise and user-friendliness-wise, IMHO better to require explicit initialization (some special option or separate script), and error-out if files expected from such an initialization do not exist, than to write in the user's home directory, or anywhere outside where explicit options and arguments point, for that matter. But again, that's IMHO. brgds, H-P
