From owner-svn-src-all@freebsd.org Fri Apr 14 20:41:28 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 364D4D3AA90; Fri, 14 Apr 2017 20:41:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (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 E7C89363; Fri, 14 Apr 2017 20:41:27 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-yb0-x231.google.com with SMTP id l201so21111924ybf.0; Fri, 14 Apr 2017 13:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PFysNNThXkZBd3AVBwh5zjHDsdLezan9OO7QdSDNKZE=; b=bcZod9JZK1oK2kWjO1mKm3qgoL7yqzJNOkx+6lH5NSwGJM6W9VHvzot6UritHasq6o ubhZjFrzatdYbMT/QfQYDA9FntE3upSVXrHSHQzgKAA3Lf6q2YpeY94/AuzmZeamQKQC S07YKVhFf3gSYl+pRAfc/7YzVro+aBo2Ru2ua/7NgxVbz3mwiuCeUsLzsBCPPQKeeCj8 KA4unDUksOv8Sc//2biUHL0qal5xY2qEOmkw8wm1q/4B1h6cm0+4Pcp0YVay7EQ5Rjdq TMQZ7ZJVLQTip82mz4rTXgXM0SL7mNfT9PV0e9f6gpv/vteXdIu8tf/y8FOIAeAHWlfV CAhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PFysNNThXkZBd3AVBwh5zjHDsdLezan9OO7QdSDNKZE=; b=ajBjKY5Snf6tnEht0ulXqMzA1OT9xdlMQCknAi5Obd4PL7R2zsWupGVIaLgmfOkW4v pHTqtfpr/1W7+6noJfJanO9/nBuuns1juQUEHciquP89G0UPORKzLu4DUtxFdYZhgtIq d8KAHQ7VksVRKP6qPzbVmd4T0+WXyHFYOHKZrVaLGP1Y/rHoFKznuOIxrsEB4CQQbjrz Q+sX5HY8B7H6yE93pltToQH5vk8OTpd3MGGHxK3Odq45qqlabN4+UfatL498aI6uB7at aRucJm7LAYum1wRAU3xiC2FMn1mDmZl2G+62xiuvuUzoH/5fuDFOUjoDXfMLtP4/nQEN enYQ== X-Gm-Message-State: AN3rC/5uEjZEocwS8jfE7tKTibjJEX78mfrrxoKw65xdJo+h9RezwLcj 1xFNOi+RLTlqtLNxPIiKzdOdUmV2kP+D X-Received: by 10.37.165.8 with SMTP id h8mr7369341ybi.113.1492202485931; Fri, 14 Apr 2017 13:41:25 -0700 (PDT) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.129.20.214 with HTTP; Fri, 14 Apr 2017 13:41:25 -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: Alan Somers Date: Fri, 14 Apr 2017 14:41:25 -0600 X-Google-Sender-Auth: _BCSZgroLun7ev6CXaeVUzQSnTY Message-ID: Subject: Re: svn commit: r316938 - head/sbin/savecore To: Mark Johnston Cc: 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 20:41:28 -0000 On Fri, Apr 14, 2017 at 2:29 PM, Mark Johnston wrote: > On Fri, Apr 14, 2017 at 01:49:51PM -0600, Alan Somers wrote: >> On Fri, Apr 14, 2017 at 1:41 PM, Ngie Cooper wrote: >> > Author: ngie >> > Date: Fri Apr 14 19:41:48 2017 >> > New Revision: 316938 >> > URL: https://svnweb.freebsd.org/changeset/base/316938 >> > >> > Log: >> > savecore: fix space calculation with respect to `minfree` in check_space(..) >> > >> > - Use strtoll(3) instead of atoi(3), because atoi(3) limits the >> > representable data to INT_MAX. Check the values received from >> > strtoll(3), trimming trailing whitespace off the end to maintain >> > POLA. >> > - Use `KiB` instead of `kB` when describing free space, total space, >> > etc. I am now fully aware of `KiB` being the IEC standard for 1024 >> > bytes and `kB` being the IEC standard for 1000 bytes. >> > - Store available number of KiB in `available` so it can be more >> > easily queried and compared to ensure that there are enough KiB to >> > store the dump image on disk. >> > - Print out the reserved space on disk, per `minfree`, so end-users >> > can troubleshoot why check_space(..) is reporting that there isn't >> > enough free space. >> > >> > MFC after: 7 weeks >> > Reviewed by: Anton Rang (earlier diff), cem (earlier diff) >> > Tested with: positive/negative cases (see review); make tinderbox >> > Sponsored by: Dell EMC Isilon >> > Differential Revision: D10379 >> >> The free space calculation is still uselessly conservative, because it >> doesn't account for the fact that core dumps will always be either >> spare or compressed. The result is that savecore will frequently >> refuse to save corefiles even when there's plenty of space. I >> proposed removing the space check altogether in >> https://reviews.freebsd.org/D2587. However, I agreed to wait until >> after the compressed core dump feature was merged, because then mostly >> accurate space checks will be possible. AFAIK the compressed core >> dump feature still hasn't been finished. > > I had held off on it for a while because it was going to conflict with > the work to add encrypted dump support, which of course has finished. > > The patch to add compression support is here and should largely still > work: > https://people.freebsd.org/~markj/patches/core-compression/20141110-kern_dump.diff > > I've been hesitant about pushing it forward: > - The dump_write* APIs need some simplification after the addition of > encrypted dump support and support for dumping to 4Kn drives. > - 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. > > If anyone has some insight on the second of these two points, I'd > appreciate hearing it. I think compress then encrypt should be ok. AFAIK all attacks against compress-then-encrypt systems have involved either incredibly short payloads that are easy to guess, or a stream of separately compressed blocks that can be fingerprinted. But core dumps are very long, and they can't be fingerprinted in whole because they're unique. If you were to encrypt each page individually then pages could be fingerprinted, so don't do that. Instead, compress the entire core dump as a single stream and you should be ok. -Alan