Custom kernel for NAT and PF ?

[Polytropon]

On Fri, 13 May 2016 10:17:41 +0200, Damien Fleuriot 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.

That is a very valid point of view. While it doesn't matter to the
usual desktop PC, a "small footprint appliance" does definitely benefit
from this approach. For example, on a security-related installation
where you build from source anyway (because security updates are in
SVN earlier than they appear as binary upgrades), you often have a
custom kernel and a restrictive src.conf, just to make sure you can
exactly define that "footprint" (in terms of what the system consists
of) as close as possible. You don't include what you don't need, so
there are less "moving parts" in case something would break.

Hardware limitations aren't the only reason for the "small footprint"
concept. :-)



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...