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  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]
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

Powered by blists - more mailing lists