Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964841Ab2KEXE3 (ORCPT ); Mon, 5 Nov 2012 18:04:29 -0500 Received: from terminus.zytor.com ([198.137.202.10]:41748 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751818Ab2KEXEZ (ORCPT ); Mon, 5 Nov 2012 18:04:25 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <20121105204249.GG28720@redhat.com> References: <1351276649.18115.217.camel@falcor> <20121101131003.GA14573@redhat.com> <20121101135356.GA15659@redhat.com> <1351780159.15708.17.camel@falcor> <20121101144304.GA15821@redhat.com> <20121101145225.GB10269@srcf.ucam.org> <20121102132318.GA3300@redhat.com> <87boffd727.fsf@xmission.com> <20121105180353.GC28720@redhat.com> <87mwyv96mn.fsf@xmission.com> <20121105204249.GG28720@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: Kdump with signed images From: "H. Peter Anvin" Date: Tue, 06 Nov 2012 00:01:56 +0100 To: Vivek Goyal , "Eric W. Biederman" CC: Matthew Garrett , Mimi Zohar , Khalid Aziz , kexec@lists.infradead.org, horms@verge.net.au, Dave Young , linux kernel mailing list , Dmitry Kasatkin , Roberto Sassu , Kees Cook , Peter Jones Message-ID: <9db4437f-7dbb-427f-968c-685500b89877@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1725 Lines: 46 Yes, it is unlikely you can pare thibgs down more than klibc. Vivek Goyal wrote: >On Mon, Nov 05, 2012 at 11:44:48AM -0800, Eric W. Biederman wrote: >> Vivek Goyal writes: >> >> > On Fri, Nov 02, 2012 at 02:32:48PM -0700, Eric W. Biederman wrote: >> >> >> >> It needs to be checked but /sbin/kexec should not use any >functions that >> >> trigger nss switch. No user or password or host name lookup >should be >> >> happening. >> > >> > I also think that we don't call routines which trigger nss switch >but >> > be probably can't rely on that as somebody might introduce it in >> > future. So we need more robust mechanism to prevent it than just >code >> > inspection. >> >> The fact that we shouldn't use those routines is enough to let us >> walk down a path where they are not used. Either with a static glibc >> linked told to use no nss modules (--enable-static-nss ?), or with >> another more restricted libc. > >Is there anything wrong with using uClibc? Trying to link again >customized glibc (with --enable-static-nss) sounds just extra work for >build environments. Are there know restricted libc or we need to create >one with passing more compile time options to libc. > >Instead of doing more work in an attempt to create restricted libc, >it might be easier to just link against any already available >restricted library. > >Thanks >Vivek -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/