[BUG]: PCSX2 tries to access the Berkeley Packet Filter (bpf) on macOS

[checktext00]

Describe the Bug

After installing PCSX2 on macOS, I got this scary warning in Little Snitch with the Endpoint Security System Extension installed

According to Little Snitch firewall documentation about the Berkeley Packet Filter:

BPF allows injection of data packets at the network interface. This means that a (privileged) app which opens a BPF device can send any data packet to any destination. The packet is injected directly at the network interface layer, circumventing all firewalls.

I even have the PCSX2 automatic update check option disabled, and this throws up a scary warning in Little Snitch

(this only seems to happen after opening the PCSX2 settings menu window the first time after launching the app - also PCSX2 won't actually let me access the settings menu until after I accept or reject the Little Snitch popup)

after running sudo opensnoop -n PCSX2 I saw that PCSX2 tried to access both /dev/bpf and /dev/bpf0

using macOS Big Sur 11.7.10 PCSX2-v1.7.5708.app

I'm getting the warning without a pcap adapter enabled (I don't really know what a PCAP adapter would be), but just for maximum troubleshooting I will say that:

1. I have Tunnelblick installed for accessing a VPN (all default option using the default utun device which is part of macOS - see info here) - but for testing I disconnected all VPNs and quit Tunnelblick and still got the bpf access issue with PCSX2
2. I am using specifically the Endpoint Security System Extension of Little Snitch which is an extra option that needs to be enabled and installed (see info here)

In order to control access to file system objects (/dev/bpf), Little Snitch needs to register an Endpoint Security System Extension. This is an additional install. Choose Little Snitch > Preferences > Advanced > Install Endpoint Security

3. Little Snitch does have a command line option to capture traffic in a pcap format but I have not enabled that (see info here)

Thanks for looking into this

Reproduction Steps

Launch PCSX2 and access the PCSX2 preferences/options menu

Expected Behavior

PCSX2 should not attempt to access /dev/bpf or /dev/bpf0

PCSX2 Revision

1.7.5708

Operating System

macOS 11 (Big Sur)

If Linux - Specify Distro

No response

Logs & Dumps

No response

[TheLastRar]

Launch PCSX2 and access the PCSX2 preferences/options menu

My initial suspicion is that we trigger this when getting the list of adapters for the Network and HDD settings panel

We ask each network backend what adapters it supports here https://github.com/PCSX2/pcsx2/blob/b94a232b314c59d63433facd44ffda3a8d0be39b/pcsx2-qt/Settings/DEV9SettingsWidget.cpp#L71-L78

Which then calls pcap_findalldevs() here https://github.com/PCSX2/pcsx2/blob/b94a232b314c59d63433facd44ffda3a8d0be39b/pcsx2/DEV9/pcap_io.cpp#L204

I guess this function tries to access /dev/bpf and /dev/bpf0, and trips the Endpoint Security System Extension you are using.

I'm, however, not a MAC dev, so I'm not able to verify if my suspicion is correct, nor determine the best approach to resolve this.

[stenzek]

I guess we could lazily populate the adapter list if ethernet isn't enabled. Probably not the worst idea anyway.

I'd also say this isn't really a bug though, and such a change would be purely from a performance perspective. MacOS doesn't restrict access to this resource itself.

[TheLastRar]

Can you give https://github.com/PCSX2/pcsx2/pull/11093 a shot You will probably still get the Berkeley Packet Filter popup when you go to the Network and HDD settings panel, but the other settings panels won't trigger it

[checktext00]

thanks guys

I'd also say this isn't really a bug though, and such a change would be purely from a performance perspective. MacOS doesn't restrict access to this resource itself.

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

[stenzek]

You will probably still get the Berkeley Packet Filter popup when you go to the Network and HDD settings panel, but the other settings panels won't trigger it

Is the dropdown disabled when ethernet is disabled? You could defer it until then (which is what I was thinking anyway).

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

If it was, then I'd think that MacOS would require an entitlement. List of adapters is hardly sensitive/private information.

[TheLastRar]

Is the dropdown disabled when ethernet is disabled? You could defer it until then (which is what I was thinking anyway).

Done

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

If it was, then I'd think that MacOS would require an entitlement. List of adapters is hardly sensitive/private information.

Had a look though the libpcap source pcap_findalldevs will check if the adapter can be used for capture by briefly opening it See pcap-bpf.c, which sets the check_usable parameter of pcapint_findalldevs_interfaces to check_bpf_bindable(). check_bpf_bindable calls bpf_open_and_bind which (via bpf_open) opens /dev/bpf*.

I guess that's what we get when we ask a packet capture library what adapters we can use it with

I was looking at it more as a potential security issue (I've never seen another app try to access the bpf)

It's worth noting that (I believe) /dev/bpf* is by default only accessible when running sudo You would need to chmod the file to allow non elevated processes to access it. PCSX2 won't do this, but other packages, such as wireshark, can

[TellowKrinkle]

It's worth noting that (I believe) /dev/bpf* is by default only accessible when running sudo

Correct. On a normal install, applications cannot use bpf devices without root.