linux-kernel - Re: [PATCH 2/2] zram: support deflate-specific params

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: <qddzdpkjsi6plu7jih5vau3xq5kjucnocoeoz7ewqbrzoiwgt6@zio43bbj5r2z>
Date: Thu, 15 May 2025 12:32:39 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Zaslonko Mikhail <zaslonko@...ux.ibm.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	Heiko Carstens <hca@...ux.ibm.com>, Ilya Leoshkevich <iii@...ux.ibm.com>
Subject: Re: [PATCH 2/2] zram: support deflate-specific params

On (25/05/15 11:24), Herbert Xu wrote:
> On Thu, May 15, 2025 at 12:19:25PM +0900, Sergey Senozhatsky wrote:
> >
> > OK, so do we want to limit user-space and permit only "raw deflate"
> > winbits values. that is only negative ones (either explicitly or
> > implicitly (by negating the value before zlib API calls))?
> 
> I would suggest that we stick with the zlib values, but filter
> out the ones that we don't support/use currently.  If you've already
> exported this to user-space then obviously you'll need to decide
> on how to maintain compatibility but that should be specific to
> zram.

This is not exported yet.

I lean toward not filtering/limiting anything and just permit
what include/linux/zlib.h promises [1].  Would that be OK for
Crypto API?

[1]
----

     The windowBits parameter is the base two logarithm of the maximum window
   size (the size of the history buffer).  It should be in the range 8..15 for
   this version of the library. The default value is 15 if inflateInit is used
   instead. windowBits must be greater than or equal to the windowBits value
   provided to deflateInit2() while compressing, or it must be equal to 15 if
   deflateInit2() was not used. If a compressed stream with a larger window
   size is given as input, inflate() will return with the error code
   Z_DATA_ERROR instead of trying to allocate a larger window.

     windowBits can also be -8..-15 for raw inflate. In this case, -windowBits
   determines the window size. inflate() will then process raw deflate data,
   not looking for a zlib or gzip header, not generating a check value, and not
   looking for any check values for comparison at the end of the stream. This
   is for use with other formats that use the deflate compressed data format
   such as zip.  Those formats provide their own check values. If a custom
   format is developed using the raw deflate format for compressed data, it is
   recommended that a check value such as an adler32 or a crc32 be applied to
   the uncompressed data as is done in the zlib, gzip, and zip formats.  For
   most applications, the zlib format should be used as is. Note that comments
   above on the use in deflateInit2() applies to the magnitude of windowBits.

     windowBits can also be greater than 15 for optional gzip decoding. Add
   32 to windowBits to enable zlib and gzip decoding with automatic header
   detection, or add 16 to decode only the gzip format (the zlib format will
   return a Z_DATA_ERROR).  If a gzip stream is being decoded, strm->adler is
   a crc32 instead of an adler32.