Date: Sun, 20 Feb 2011 14:16:41 +0200
From: [1][email protected]
On 19 Feb 2011 at 15:39, Dean Takemori wrote:
But it's not clear to me what the "most correct" or most futureproof way
to merge
three moving targets (kernel, grsec and aufs2.1) together.
Suggestions or comments anyone?
PaX constifies the fields of struct address_space_operations to prevent
exactly what
aufs/etc want to do. obviously you can't have it both ways, something has
to give ;).
if you want aufs, revert this chunk in PaX.
From: [2][email protected]
Date: February 20, 2011 3:24:36 AM HST
Dean Takemori:
Sources:
linux-2.6.32.28
grsecurity-2.2.1-2.6.32.28-201102121148.patch
aufs2.1-32 (2011/02/14 standalone git snapshot)
linux-2.6.32.28/fs/aufs/dynop.c: In function 'dy_aop':
linux-2.6.32.28/fs/aufs/dynop.c:179:2: error: assignment of read-only
member 'writepage'
:::
This looks similar to
[3]http://www.mail-archive.com/[email protected]/msg02644.h
tml
And there is a patch for it.
[4]http://www.mail-archive.com/[email protected]/msg02649.h
tml
While their versions are different from yours, I think this is what you
should try first.
Aha. I think I understand the issue now.
Loosely speaking, the PaX patch uses the compiler to prevent changes to
filesystem structures that "ought not" to be changed. On the other hand
aufs is by design not an ordinary filesystem and performes some "magic"
behind the scenes to make it appear ordinary to users.
So the two projects are at odds in this area, and a code conflict is
the result.
The cleanest general solution I can see is if the PaX team would
accept some sort of CONFIG_PAX_CONSTIFY_FS_H kernel config option with some
appropriate ugliness
#ifdef CONFIG_PAX_CONSTIFY_FS_H
# define PAX_FS_H_CONST const
#else
# define PAX_FS_H_CONST
#endif
...
struct address_space_operations {
int (* PAX_FS_H_CONST writepage)...
...
But there may be plenty of reasons unobvious to me why such a thing
would not be acceptable.
Many thanks,
-dean takemori
References
1. mailto:[email protected]
2. mailto:[email protected]
3. http://www.mail-archive.com/[email protected]/msg02644.html
4. http://www.mail-archive.com/[email protected]/msg02649.html
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
