Custom kernel for NAT and PF ?

[Damien Fleuriot]

On 13 May 2016 at 06:34, Shane Ambler <FreeBSD at shaneware.biz> wrote:

> On 12/05/2016 19:49, Damien Fleuriot wrote:
>
>> On 12 May 2016 at 09:13, krad <kraduk at gmail.com> wrote:
>>
>> Agreed
>>>
>>> On 12 May 2016 at 01:30, Michael B. Eichorn <ike at michaeleichorn.com>
>>> wrote:
>>>
>>> On Wed, 2016-05-11 at 15:03 -0500, Chris Hale wrote:
>>>>
>>>>> I'm having to rebuild an old freebsd/pf firewall that uses ALTQ and
>>>>> some
>>>>> NAT directives.  Would I need a custom kernel for NAT if I took out
>>>>> all of
>>>>> the ALTQ references?
>>>>>
>>>>>
>>>> The generic kernel is all you need for NAT with pf.
>>>>
>>>
>>>
>>>
>> While GENERIC works, one can definitely argue in favour of a custom
>> kernel,
>> what does one even need audio for on a server anyways ;)
>>
>> At the very least, you get shorter compilation times for your upgrade
>> sessions so, that's that...
>>
>> Chris, if you can be bothered, do go for a custom, lightweight kernel.
>> Typical use scenarios have you remove support for audio, wifi, bluetooth,
>> usb printers, isa cards...
>>
>>
> Well 15 years ago that was pretty normal, if you only had 8MB RAM then
> you trimmed your kernel as much as you could to save some RAM.
>
> These days using the generic kernel isn't an issue. We have enough RAM
> that a few MB saved in the kernel is not noticed.
>
> Now you only need to compile a custom kernel if you want to use newer
> features. dtrace was an option previously but now is available in
> generic, ipsec is a current feature you need a custom kernel for, which
> is planned to be available in generic for 11.0
>
> If you have a look through a recent /boot/kernel you will find that the
> kernels nowadays are only about 20MB with another ~450MB in loadable
> modules that don't do anything unless they are loaded for the hardware
> or features you want.
>
> Don't want sound? - don't add snd_hda_load="YES" to your loader.conf.
>
> You may argue that disabling things can speed up the kernel, I don't
> believe a non-loaded module adds any execution time. And how often are
> your cpu's at 100% capacity that the small saving you can get in the
> kernel makes a noticeable difference to performance?
>
> So yes you can save some compile time and a few MB of disk space. Your
> saving what, maybe 10-20 mins? Not like you just sit there doing nothing
> until the compile finishes.
>
>
You make cogent arguments Shane, however I am of a different mind.


See, trimming your kernel has many advantages, small ones certainly but
they do add up :
- smaller compile times
- smaller memory footprint
- less chance of being affected by bugs
- reduced attack surface

In the context of a firewall, I'd rather go for the (much) reduced attack
surface.

Less drivers and options built-in means less attack venues for remote
threats.