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-next>] [day] [month] [year] [list]
Date:	Tue, 18 Sep 2012 12:44:21 +0300
From:	"Kasatkin, Dmitry" <dmitry.kasatkin@...el.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-fsdevel@...r.kernel.org,
	linux-security-module <linux-security-module@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	James Morris <jmorris@...ei.org>
Subject: IMA policy search speedup

Hello Linus,

I have asked this question already 2 times in fsdevel but have not got
any single response.

Certain file system types and partitions will never be measured or
appraised depending on the IMA policy.
For example, pseudo file systems are not measured and appraised.
In upstream IMA implementation policy will be checked again and again
for every inode in the filesystem.
It happens thousands times per second. That is absolute waste of CPU
and may be batter resources.

To overcome such issue I would like to have a flag in super block data structure
which can be set once if IMA does not need to measure anything from a partition.
The flag might be tested by ima hooks to return without doing anything.

I looked to <linux/fs.h> and found that there is a possibility to to
add additional flag for sb->s_flags.
For example

#define MS_NOT_IMA              (1<<25) /* NOT_IMA */
#define IS_I_NOT_IMA(inode)   __IS_FLG(inode, MS_NOT_IMA)


Another way is to add additional dedicated integrity related member to
the sb structure.
struct super_block {
...
#ifdef CONFIG_INTEGRITY
      int s_integrity;
#endif
};

Obviously there are only few super blocks in the system and few bytes
will not harm.

Can you please advice about this?

Thanks,
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists