From owner-svn-src-head@freebsd.org Fri Apr 14 22:05:47 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ABB50D3CD77; Fri, 14 Apr 2017 22:05:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 627172C1; Fri, 14 Apr 2017 22:05:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt0-x235.google.com with SMTP id c45so71856139qtb.1; Fri, 14 Apr 2017 15:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=7gopmosH31OJwG+IolzNb79ufMc3IE6ZJvahzevUjHM=; b=Fy3+1q22QWwTSPhR1Egbd9JXHFQYcRvMZlL0VQCHPgmxS40yO/PBjb7Na2h4D3jCbY iA2/F24pbWu735ZOuZFGNW5QpNbgoPKAgYdF8Gx3YEvzZMuqxoD2NZivJBOYSFD3KZu6 hu6W0ZA4/zLd2Q1+yqJgYVVZbxn0HW6iK8/25A33I4zKQVJnxsFga3S4yOig4CJVv6PF lxH7OM3Fq8eAaXOZlo1ww4HSwFLt3Oz22YXrsYhfBFXnoAAjnOeNEe08F/+YMGBiourG ex6uOfn4c0UilhHSKCzJXtrHp4jyEEWgEbKPa3LB7Ni2apmcMEnojAyJdYWsPHdaneRa tMRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=7gopmosH31OJwG+IolzNb79ufMc3IE6ZJvahzevUjHM=; b=o5jQ39wIdNNfAXEdQlwDlX8Gy7XyVgPA+wm45MjPTKC0Hh2+YeTEgfisurKeB2GUB7 y4z7v6MbV0Vt8PQjPqibPCHKNussVTUCnjDx5PtuizKvSsDQbY4QhmFpAuCcDRpb9nRH vbKAbQfjTUSuubh4sEf+CmADdpjbaoxdYDmKREJGd+1ojVwniVPKPn8p3Rx2peKbT2XZ DSoCbO+96XpjNg7cX8O1g960zSCj7On/RfdE/CaMnczIGf50iVDkEvG4dlIJHrkEzd7m 0zjoCK9pB/9l9SytDghFvhObx6ziOie7E+7bfhimrhfLhhcG8nDMMJmdVXaGWHSxqOkE yqQg== X-Gm-Message-State: AN3rC/5laKizfZF37qatmzh/5azp4aQZDAhg02jkSAZRdbjLHTwUc3I6 ziXUHUZawm2Bgg== X-Received: by 10.237.36.212 with SMTP id u20mr9823403qtc.217.1492207546548; Fri, 14 Apr 2017 15:05:46 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id t22sm2023063qke.49.2017.04.14.15.05.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 15:05:45 -0700 (PDT) Sender: Mark Johnston Date: Fri, 14 Apr 2017 15:05:25 -0700 From: Mark Johnston To: Xin LI Cc: Alan Somers , Ngie Cooper , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r316938 - head/sbin/savecore Message-ID: <20170414220525.GF5039@wkstn-mjohnston.west.isilon.com> References: <201704141941.v3EJfmCW003347@repo.freebsd.org> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 22:05:47 -0000 On Fri, Apr 14, 2017 at 02:28:57PM -0700, Xin LI wrote: > On Fri, Apr 14, 2017 at 1:29 PM, Mark Johnston wrote: > > - I'm not sure how encryption should compose with compression. It seems > > intuitively obvious that we should compress before encrypting if the > > compression is to be of any use, but I don't know enough to know > > whether the compression might somehow compromise the effectiveness of > > the encryption. > > I think the biggest concern is the added code involved in the dump > process (which happen when the kernel is already unhealthy), which can > jeopardize it and defeat the usefulness of having a crash dump being > set up in the first place. I agree in principle but this doesn't appear to cause problems in practice. zlib allocates memory only at initialization time, so its requirements in panic context are quite minimal. I wrote a little bit of zlib glue, used currently for compressed userland core dumps, which works properly in panic context as well. > And with textdumps available, the benefit > of having compression is limited because we can request for minidump > or full dumps only when the textdumps are not good enough for > diagnosing the kernel bug. Sure, but in this case the compression may be vital. > > I don't think security (e.g. leaking information because of the use of > compression) is a very big concern in this context because in order > for the potential attacker to read the raw material needs a > compromised system (unlike an attack from the network, where someone > who controls the network would have access to the raw material); the > dump is usually quite large, and measuring downtime would be hard at > that scale. Ok. > > By the way (not meant to bikeshed) if I was to do this I'd prefer > using lz4 or something that compresses faster than zlib. I agree, but I think the existing lz4 implementation in the kernel is not so well suited to running after a panic. It seems fixable, but compression speed also isn't hugely important here IMO.