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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Dec 2022 00:35:24 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Ye Bin <yebin@...weicloud.com>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, jack@...e.cz,
        Ye Bin <yebin10@...wei.com>,
        syzbot+4d99a966fd74bdeeec36@...kaller.appspotmail.com
Subject: Re: [PATCH v3 1/4] ext4: fix WARNING in ext4_expand_extra_isize_ea

In general, please don't use commit summaries like:

	ext4: fix WARNING in ext4_expand_extra_isize_ea
	
The commit summary should be a summary of what the change *does*.  A
description of *why* the change is needed is properly placed in the
body of the description.  So something like "ext4: clamp
EXT4_XATTR_SIZE_MAX to XATTR_SIZE_MAX" would be a better one-line
commit summary.

That being said, I've decided to not apply this patch.  A 16 MB
extended attribute size is not _that_ insane, although admittedly it's
quite bit larger than any other file system or OS supports (unless you
include Solaris and NTFS's alternate data forks as "extended
attributes").

I personally don't think the mm/page_alloc warning is that big of a
deal (even if it does cause a Syzbot report), and if you really do
care about suppressing the warning, using the kvmalloc() instead of
kmalloc() will do that --- and it does make ext4 friendly in the case
of where we are storing, say, a 30KB Windows ACL as an extended
attribute, since it avoided needing to make a order 3 page allocation.
(Which again, as far as I'm concerned, is more important than the
suppressing the page_alloc warning.)

We may ultimately decide to clamp EXT4_XATTR_SIZE_MAX to
XATTR_SIZE_MAX, but one could imagine some system attribute that in
the future might want to be larger than 32k, that wouldn't be accessed
via the standard xattr API.  That seems unlikely, but I want to keep
our options open.

Cheers,

					- Ted

Powered by blists - more mailing lists