From owner-freebsd-security@FreeBSD.ORG Wed May 1 06:23:58 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 95F9AB2E; Wed, 1 May 2013 06:23:58 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1CD1D3C; Wed, 1 May 2013 06:23:58 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id ta17so1063106obb.40 for ; Tue, 30 Apr 2013 23:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CFHMDN5RmaaEyYGDJg4EtjA3utqiu366uIbmFEn6H8Q=; b=AeMuShyCbMuRxO2zPjQkLt6CkX/mDxVhQv976uSRWEYtvdzE7+ougz/h2K9RWWWuAA rzxJIhe77Vf1Wy32QUIYgREbO+wFAuO6DOanZqCajW0Xigy1K1elltyV4phOw1KgCUNN M/rzKudCMStUht6wmAjS4VqB70aF/WbmFBBn+GZAjojI5K/OklwM7MvyVJPwPBs1svYQ sIUXdunOyLYlRtlM5Ph0UB1YFWMTBeSJJUqQ1g3N6yLV34B02qqecCMK0DDACb/xhiFc A2Hq6UfvXAzhC2sVW5BcSLAWP18+ZSLD+Dy/UUEUpRzStWfGnee54MpqRpgOU/TjP6Kp zLqw== MIME-Version: 1.0 X-Received: by 10.60.76.234 with SMTP id n10mr360012oew.63.1367389437844; Tue, 30 Apr 2013 23:23:57 -0700 (PDT) Received: by 10.182.161.100 with HTTP; Tue, 30 Apr 2013 23:23:57 -0700 (PDT) In-Reply-To: <201305010243.UAA08356@lariat.net> References: <201304292208.QAA16119@lariat.net> <20130430034603.GF1588@glenbarber.us> <201304300416.WAA20729@lariat.net> <20130430042415.GG1588@glenbarber.us> <201304301936.NAA02519@lariat.net> <20130430211531.GA1621@glenbarber.us> <201304302241.QAA05359@lariat.net> <20130430224850.GA1579@glenbarber.us> <201305010149.TAA07809@lariat.net> <20130501022228.GD1579@glenbarber.us> <201305010243.UAA08356@lariat.net> Date: Wed, 1 May 2013 08:23:57 +0200 Message-ID: Subject: Re: FreeBSD Security Advisory FreeBSD-SA-13:05.nfsserver From: Oliver Pinter To: Brett Glass Content-Type: text/plain; charset=ISO-8859-1 Cc: Glen Barber , Chris Rees , Colin Percival , freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 06:23:58 -0000 On 5/1/13, Brett Glass wrote: > At 08:22 PM 4/30/2013, Glen Barber wrote: > >>Maybe I am missing the fundamental usage of freebsd-update(8). How does >>using freebsd-update(8) to fetch src/ updates install a new kernel? > > When you use freebsd-update(8) in the usual manner, it fetches all of the > source and binary updates necessary to bring the system up to the latest > security patch level. When a userland binary is updated, it overwrites the > source and binary. But when the kernel is updated, it moves /boot/kernel to > /boot/kernel.old and then drops a GENERIC kernel into /boot/kernel. If > there were no loadable modules in /boot/kernel at the start of the update, > none are placed in /boot/kernel afterward. This is problematic, because > the custom kernel that previously resided in /boot/kernel might have had > some > necessary modules built in... and they will not be available, either as > compiled-in modules or as loadable modules, at the next reboot. > > To leave the system in a precarious state, where a power glitch could > leave it unable to reboot, does not seem to me like a good idea. If > /boot/GENERIC exists (which means that the administrator has built a custom > kernel and saved the GENERIC kernel there), best to update /boot/GENERIC and > > leave the custom kernel in place, to be rebuilt if needed. > > The administrator will probably want to rebuild his or her custom kernel > after the update... unless it didn't contain the code that was fixed by > the patch, in which case there's no need. (My kernel didn't contain NFS, > and I didn't build any loadable NFS modules, so I actually didn't need a > rebuild.) The ultimate solution for you described in loader.conf(5). kernel Name of the kernel to be loaded. If no kernel name is set, no additional modules will be loaded. The name must be a subdirectory of /boot that contains a kernel. And set INSTKERNNAME in make.conf - this are in Makefile.inc1. --8<-- #!/bin/sh echo "INSTKERNNAME=magickernel" >> /etc/make.conf echo "kernel=magickernel" >> /boot/loader.conf cd /usr/src make kernel -->8-- good luck :) > > --Brett Glass > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" >