Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2624114ybl; Mon, 19 Aug 2019 05:11:51 -0700 (PDT) X-Google-Smtp-Source: APXvYqxh16w+yjsoLPYlhu6H6KsGAvCbhoVungscdroRlujeirSNU+zzqb5Gdo8D/lvN7+w3bh9O X-Received: by 2002:a17:90a:a40f:: with SMTP id y15mr18553083pjp.69.1566216711473; Mon, 19 Aug 2019 05:11:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566216711; cv=none; d=google.com; s=arc-20160816; b=Qni+8xzdSxiO0gkQkgBX7yPZjfRAMGBmknyOs70C0wWlk0TExb+2gTrkWskpT84Lc4 k033DDXMLaRN74rGS/8qE40oaELjvPBlD0RWBmd7sjhbVGANrzXPLueO7JK3X6EhPPSY ewugCsMduxbNQMS7328QMQ0AyOh40W5BetWCKuJwek4AzyTQSlO0f3OGZUarZ81EtA0H TV631qwHPJoRLlosFD6qg8O389/iAN6oNLT+6kq0g3Ax9tNTssBW0PKPSbY5Dny85iAZ 3ulAmwKRAFfrJ7osdJldxwEUhxmuxjROWXgNGEl0elHy2CKWheqdPIgRxR+JITiZop/6 XR2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=tod989bewvsh+ihp8Ytq66nz+m1s8UlnuaOcAgZNr9I=; b=tuJbBRKS64RhWiuWMUfXP4M76vKT32jz7vNoAtzEqTDyx2CwHhs2TiEq6UdgnSEVFZ 6W/s6envb8gN5ph2Zsa5P2rMWplRiMx0oVOk5so0FB6X/5MkoK+c3fgzGEbNR0CuvIAz vXaUhYhvPN3lgIESMWSfJo7RPtWc5Hh3UuJwxcZgytUeOXfK5JYjNpm+A38n5SE6xPI+ 85JnqxaTQBGBcygQ0yH91QTkYeqY0sy5Q9YXsTWSsC5m81a+osQv3J/6k/Pv/TdBR3gO i+mZebhw9zoItx72s4YM4TxXbqiVo/7LIInR+n1cZPqcu5PnKcWwzoOvyGzbrMqPEOqf eVsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@digidescorp.com header.s=google header.b=HYkuq8ew; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v6si9785688plp.4.2019.08.19.05.11.36; Mon, 19 Aug 2019 05:11:51 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@digidescorp.com header.s=google header.b=HYkuq8ew; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727308AbfHSMK1 (ORCPT + 99 others); Mon, 19 Aug 2019 08:10:27 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:42298 "EHLO mail-io1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726594AbfHSMK0 (ORCPT ); Mon, 19 Aug 2019 08:10:26 -0400 Received: by mail-io1-f67.google.com with SMTP id e20so3663267iob.9 for ; Mon, 19 Aug 2019 05:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digidescorp.com; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=tod989bewvsh+ihp8Ytq66nz+m1s8UlnuaOcAgZNr9I=; b=HYkuq8ewGkngiYR7/rEWOG+x8/Qu0BhykyLbB+7rmgyN4+6VIMQX9uvy77d4jg0RZe QRP4tssOtnliZu+Rx8kkdgeB5copPf7SCFLPHBMAwzcsMA0JxWWZ8kgWd/ZOnzJn159X qAIfeK+C5PxkQFfW4t2R18w5ghIh8TWsgAIks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tod989bewvsh+ihp8Ytq66nz+m1s8UlnuaOcAgZNr9I=; b=W2soGVV2NVQ26vhHcDiq89iVSNADSjE5l3+RYg9Ec09azHZ2V1e/k6TI05Whg8tyPR QHiNZtI6W9GRHAHyQqLH0gQiNqKmz1oq6oEfvoVkoZzps4RkNHaIwT/micj9dRSgdAUX KkXU3GDzz77MZwqGQsWWoTV93X+a1rr5oq1nvmlvyS7EIzGgCoUs2gsmKdWr2Lr2VanX LzyiEzX0xJb+rPAEZ6ZIN/hAIRwMyCOu02zJlP1kstB2WKt6GMQIvDYT8zdfsZDnCNFz C/r9/ZoWbCPsGGxTiOI2s2fUsineqonkNSlpPOW9bf33lrHzf9vtGMxqGkt3hD6H3psc 4OOA== X-Gm-Message-State: APjAAAVWvsg6hMGRN3DL/nzAA5eb2s2r/sNpu1x0UwyxNoh43OZSj0S2 YwoPL9E+ZfGL0kz17bE082moQtEDgIc= X-Received: by 2002:a6b:d008:: with SMTP id x8mr23843587ioa.129.1566216625566; Mon, 19 Aug 2019 05:10:25 -0700 (PDT) Received: from [10.10.6.134] ([50.73.98.161]) by smtp.googlemail.com with ESMTPSA id n25sm1045818iop.3.2019.08.19.05.10.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 05:10:24 -0700 (PDT) Subject: Re: [PATCH v2] udf: reduce leakage of blocks related to named streams To: Jan Kara Cc: Jan Kara , "Steven J . Magnani" , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190814125002.10869-1-steve@digidescorp.com> <20190815124218.GE14313@quack2.suse.cz> From: Steve Magnani Message-ID: <4169b326-a8ff-5fc4-0e5e-393569273267@digidescorp.com> Date: Mon, 19 Aug 2019 07:10:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190815124218.GE14313@quack2.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Jan - On 8/15/19 7:42 AM, Jan Kara wrote: > On Wed 14-08-19 07:50:02, Steven J. Magnani wrote: >> Windows is capable of creating UDF files having named streams. >> One example is the "Zone.Identifier" stream attached automatically >> to files downloaded from a network. See: >> https://msdn.microsoft.com/en-us/library/dn392609.aspx >> >> Modification of a file having one or more named streams in Linux causes >> the stream directory to become detached from the file, essentially leaking >> all blocks pertaining to the file's streams. >> >> Fix by saving off information about an inode's streams when reading it, >> for later use when its on-disk data is updated. >> >> } else { >> inode->i_blocks = le64_to_cpu(efe->logicalBlocksRecorded) << >> (inode->i_sb->s_blocksize_bits - 9); >> @@ -1498,6 +1502,16 @@ reread: >> iinfo->i_lenEAttr = le32_to_cpu(efe->lengthExtendedAttr); >> iinfo->i_lenAlloc = le32_to_cpu(efe->lengthAllocDescs); >> iinfo->i_checkpoint = le32_to_cpu(efe->checkpoint); >> + >> + /* Named streams */ >> + iinfo->i_streamdir = (efe->streamDirectoryICB.extLength != 0); >> + iinfo->i_locStreamdir = >> + lelb_to_cpu(efe->streamDirectoryICB.extLocation); >> + iinfo->i_lenStreams = le64_to_cpu(efe->objectSize); >> + if (iinfo->i_lenStreams >= inode->i_size) >> + iinfo->i_lenStreams -= inode->i_size; >> + else >> + iinfo->i_lenStreams = 0; > Hum, maybe you could just have i_objectSize instead of i_lenStreams? You > use the field just to preserve objectSize anyway so there's no point in > complicating it. > I started making this change and found that it actually complicates things more, by forcing the driver to update i_objectSize everywhere that i_size is changed. Are you sure this is what you want? ------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!" #include