R80.20 SecureXL - User Space?

[Timothy_Hall]

I keep seeing in the excellent documents by @HeikoAnkenbrand and posts by @PhoneBoy that SecureXL runs in user space starting in R80.20.  After a detailed look at an R80.20 security gateway I don't think this assertion is correct and I'm seeking clarification, I believe this is some kind of mixup with the new USFW function which is available in R80.20 but not enabled by default.

What I see on a standard R80.20 gateway is that the SecureXL kernel driver code has ballooned from 5.2MB in R80.10 to about 18MB in R80.20 and is now named with an instance number (i.e. simmod_0) which would allow multiple instances of SecureXL to be running; useful in the case of Falcon cards.  The size of the simmod code would certainly have grown since it may be capable of PSL and CPAS whereas those functions were handled in a Firewall Worker instance (fw_X) before.  The firewall worker kernel instance code (fw_X) has also grown from about 40MB to 48MB between R80.10 and R80.20. 

There is a new SecureXL-related daemon called sxl_statd in R80.20 but its functions seem to be very simple and its small size (38K) makes it impossible that it is "SecureXL running in user space".  I can't seem to find any other processes that would be "SecureXL running in User Space" unless it is somehow now part of the fw_worker_X processes which I find unlikely.

So as a bit of an experiment I enabled USFW under R80.20 according to the instructions in sk149973: How to enable USFW (User-Space Firewall) on a 23900 appliance on my 8-core VMware firewall (2/6 split) and rebooted.  In the kernel with lsmod I still see the 18MB simmod_0 but now there is only one firewall kernel driver called fwmod at 48MB.  In process space I only see one firewall worker (fwk), but I also see "fwk_wd -i 6 -i6 0" and fwk_forker so I'm pretty sure more fwk firewall workers would get forked off if needed.  It still looks like SecureXL is completely in kernel space.

The whole justification for USFW is due to the 2GB kernel limitation that was being reached by trying to load up to 40 separate instances of the firewall workers into the kernel, in R80.20 if there are 40 workers * 48MB = 1.9 GB so it makes sense that Check Point couldn't just keep adding more and more workers in the kernel.  However there is only one SecureXL simmod kernel driver and it takes up a "whopping" 18MB of kernel space, so it doesn't make sense to me to move that part into user space.

So unless I'm really missing something here I don't think the assertion that "SecureXL is in user space" is correct, at least not in R80.20, regardless of whether USFW is enabled or not.

Edit: Just looked over R80.30 and set USFW on it too, looks exactly the same as what I observed in R80.20 above.

[PhoneBoy]

You are correct that SecureXL is not in userspace. I was corrected by R&D on this point at least once 😬

One thing I know has changed in R80.20 and above is many of the checks that previously required F2F (slowpath) now happen in F2V, which DOES occur in userspace. This is why you see an improvement on connection establishment rates and you don't need to completely disable SecureXL when you use a PPPoE interface. There are some other changes I believe, and I'm sure I need a refresher on them.

I believe the long-term goal is to move all of SecureXL into userspace.

[Timothy_Hall]

Unless USFW is enabled, I don't think F2V occurs in user space either.  According to the docs F2V is SecureXL sending packets up to a firewall worker for handling (not even sure if it is related to VPN at all), then it can be sent back down to SecureXL for further processing in some cases.  I think F2V is Forward to Firewall VM and not Forward to VPN:

F2V conn match pkts	Number of packets that matched a SecureXL connection and SecureXL forwarded to the Firewall kernel.
F2V packets	Number of packets that SecureXL forwarded to the Firewall kernel and the Firewall re-injected back to SecureXL.
F2V bytes	Number of bytes that SecureXL forwarded to the Firewall kernel and the Firewall re-injected back to the SecureXL.

We really need a TechTalk on SecureXL in R80.20+, the ATRG for SecureXL R80.20+ documented the new command options and such but really didn't talk about how things are really handled under the hood at all.  Tough to make performance tuning recommendations if SecureXL is just a big black box, I realize the the conversion from synchronous to asynchronous communication between SecureXL and the Firewall Workers has made things more complicated...

[PhoneBoy]

You're right that F2V is Forward to VM (not Forward to VPN).
I could be wrong that it's in userspace, but that's what I remember from past R&D discussions.
A TechTalk on SecureXL post R80.20 is definitely in order.
@_Val_ maybe we can work on organizing this next week. 

[Dorit_Dor]

USFW is like VSX w one VS

Both still have “small” kernel. We may change it too, in the future, but it will not happen soon.