Custom kernel for NAT and PF ?

krad kraduk at gmail.com
Fri May 13 14:31:12 UTC 2016


Strictly speaking you are not correct in the compile times as simply
altering the kernel options doesnt stop the the relevant code being
compiled, it just stops it being linked. The various modules are still
built when you do a buildkernel. Playing with the src.conf could get you
faster compile times though. However this is all off topic of the OP 8)

On 13 May 2016 at 09:17, Damien Fleuriot <ml at my.gd> wrote:

>
> 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.
>
>


More information about the freebsd-questions mailing list