From owner-svn-src-all@freebsd.org Fri Apr 14 21:28:59 2017 Return-Path: Delivered-To: svn-src-all@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 A2AD9D3EDE4; Fri, 14 Apr 2017 21:28:59 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 5A38714D; Fri, 14 Apr 2017 21:28:59 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id b187so101325647oif.0; Fri, 14 Apr 2017 14:28:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eE4MoZ/XDlqBy+Axod21BQKoeZTwInjgWQdw7Pmj2qY=; b=MNggiWNNqhWBnxXjksZDQWzjo5/OyAFdHkboMwTR41qaz4q741xfZnmKljv3e7mH7I VQucMXDS8CyLk11sEGek6l1uImGH1s5du6d/rJNb0sp0OzzvZQmYt6aUHlQ2WVAVcZ9W lAJjUI4di4XWxTQ9stVnZX4Dr+eTvgENSTzUxItuEpwt7aSwOPXPMesngztZMmMCIpOC +qeKGSs2U9fv7gxHlni+OS67MgEK4MMNRXAQsuurmiDSnbMzSoOV2ClXoafv7O9zaLT4 g2mzbx/AVX7/Sf2UjswUye9iRab1he/5+n6WOtpDCTG9yevhq87pB2Zc92wv2K3i3qSg WhGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eE4MoZ/XDlqBy+Axod21BQKoeZTwInjgWQdw7Pmj2qY=; b=Gb0QDzb1HtB/UP+Oy7hrxmqBKQGac8uIF+VIB3Uwcxr79M4JzLHs0sWhEjU3vHiXoC axB/eueougec1Sq+Jsp+6w1EV6fpBIfyYNuPf7ob5DHgEFIKwu3p9fNqzaYdzsDTd5Z5 rTLv8vtSAHysoLojT8J0k0OXnkMU8IzeXiTFobVy0xyVXEHLNrgZwzgk739+RgcHNHAB vb2VsPmvnMhY/9G0uUdlDxV8KwK6sc0C5fPl3mzyzMMggsh5mr5ZsPxfDaqDAdNSNo8e j8VoJEW3BIt+TZD5OYn78HclQDZ4S2nr09NcN4UfXlLWJ2BK9oZ719k1ttojBkk4UGCd 3dqQ== X-Gm-Message-State: AN3rC/6B1vvEgY8sdj7kuEJkhGTz3gC007sjHZUMCA9Qy0CxbK4FvqWF uVGnx44jNyp/jXcFhJVHXCCWMb/DrKTIAZQ= X-Received: by 10.202.253.5 with SMTP id b5mr6249040oii.156.1492205338311; Fri, 14 Apr 2017 14:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.179 with HTTP; Fri, 14 Apr 2017 14:28:57 -0700 (PDT) In-Reply-To: <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> References: <201704141941.v3EJfmCW003347@repo.freebsd.org> <20170414202918.GD5039@wkstn-mjohnston.west.isilon.com> From: Xin LI Date: Fri, 14 Apr 2017 14:28:57 -0700 Message-ID: Subject: Re: svn commit: r316938 - head/sbin/savecore To: Mark Johnston Cc: Alan Somers , Ngie Cooper , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:28:59 -0000 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. 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. 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. 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. Cheers,