linux-ext4 - Re: Memory allocation can cause ext4 filesystem to be remounted r/o

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49ee4e84554c82d944d092fe2ec8ce82@josephdwagner.info>
Date:	Wed, 26 Jun 2013 11:53:12 -0700
From:	"Joseph D. Wagner" <joe@...ephdwagner.info>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Nagachandra P <nagachandra@...il.com>,
	Vikram MP <mp.vikram@...il.com>, <linux-ext4@...r.kernel.org>
Subject: Re: Memory allocation can cause ext4 filesystem to be remounted r/o

On 06/26/2013 7:54 am, Theodore Ts'o wrote:

> On Wed, Jun 26, 2013 at 10:02:05AM -0400, Theodore Ts'o wrote:
> 
>> In this particular case, we could reflect the error all the way up to
>> the ftruncate(2) system call. Fixing this is going to be a bit
>> involved, unfortunately; we'll need to update a fairly large number 
>> of
>> function signatures, including ext4_truncate(), ext4_ext_truncate(),
>> ext4_free_blocks(), and a number of others.
> 
> One thing that comes to mind. If we change things so that ftruncate
> reflects an ENOMEM error all the way up to userspace, one side effect
> of this is that the file may be partially truncated when ENOMEM is
> returned. Applications may not be prepared for this.

Hi Ted, it's the newbie again.  I'd like to throw out a possible
band-aid, which I know is ugly, but I'm not sure how it compares to
other ideas discussed.

What if there was a check at the start of the chain for free memory?
For example:

  1. User program calls function_x(parameter y).
  2. We know function_x() calls function_a(), function_b(), and
     function_c().
  3. Based upon our knowledge of those functions (and perhaps
     parameter y), we can _estimate_ that function_x() will require
     z bytes memory.
  4. Alter function_x() so that the first step is to check for free
     memory z.

Upside
  1. Obvious memory shortages are returned immediately, instead of 30
     steps down the chain.
  2. No risk of non-deterministic data changes (if caught; see 
downside).
  2. No risk of infinite loop due to retries.
  3. Puts a spotlight on applications that do not correctly handle
     ENOMEM, which to me is the equivalent of not correctly calling
     fsync().

Downside
  1. Does not guarantee that memory will be available when ext4 needs
     its.  Memory might be available during this pre-check, but another
     process might scoop it up between the pre-check and ext4's
     allocation.
  2. Does not catch all cases.  The check is only an estimate.

Thank you for your patience and for answering my questions.

Joseph D. Wagner
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html