Re: [LTP] Se-Linux Updates for LTP
Quoting Subrata Modak ([EMAIL PROTECTED]): On Mon, 2007-12-10 at 11:15 -0600, Serge E. Hallyn wrote: Quoting Stephen Smalley ([EMAIL PROTECTED]): On Mon, 2007-12-10 at 11:31 +0530, Subrata Modak wrote: On Fri, 2007-12-07 at 21:55 +0530, Subrata Modak wrote: Hi All, Today i had the opportunity to meet James Morris from Red Hat at FOSS.in held at Bangalore, India. After his talks on Se-Linux, we were discussing about the Policy Reference support for Se-linux available in LTP under the directory: ltp/testcases/kernel/security/selinux-testsuite/ Though i have released RHEL5 EAL4+ Certification Testsuites from IBM, i have not seen the testcases under: ltp/testcases/kernel/security/selinux-testsuite/ updated for more than an year. I am not aware exactly about the reason for the same. I would like to request you send me any updates that you may want to give to LTP for your selinux-testsuite. Can somebody give me some direction on this ?? What kind of direction are you seeking? We gave the selinux testsuite to IBM at their request, and they ported it over to the LTP and submitted it there. Joy Latten was involved in the porting; I've cc'd her above. Well i have not received any selinux testcases updates for reference policy for the last 3 quarters. What i have received and released is EAL4+ Certification Test Suite, which includes rhel5_ibm_eal4_cert_suite2.tgz. I drilled down in to this and tried to find whether there are any se-linux testcases included here, which are apparently present in ltp/testcases/kernel/security/selinux-testsuite/ directory of ltp-full-20073011.tgz (can be downloaded from http://prdownloads.sourceforge.net/ltp/ltp-full-20071130.tgz?download). I did not find either of them. They seemed different to me. So the question is who should update the testsuite. This is not just an issue for selinux, but for all the ltp tests. One could say it's Joy because she submitted the testcases. But let me warn you that that attitude will definitely decrease the likelyhood of testcases being submitted to LTP. (It'll certainly deter me) One could say it should be the selinux community in general, but that community is too large for such an answer to be helpful, and it may not be fair since they can say we didn't submit that. One could say it should be the reference policy maintainer, because I suspect refpolicy updates will be the biggest cause of breakage - but that isn't fair to him since again he didn't submit it. One might say it should be the ltp community - after the biggest advantage of submitting to LTP should be some free maintenance. However it likely doesn't have the needed expertise. Ok. This is i would say as a collective responsibility rather than somebody?? alone. It is the responsibility of the maintainer (here LTP and hence myself) to find out the validity of test cases in his/her project he/she is maintaining, and, then try to contact the author(s) of that particular test case component to provide updates if even he/she (Author(s)) has the updates themselves. Now it is upto their (Author(s)) interest to write back if they are interested. Else the Maintainer is helpless. I initiated this mail as i found it my responsibility to find out authors who actually wrote these reference policy test cases for se-linux, and which are part of LTP in ltp/testcases/kernel/security/selinux-testsuite/ directory. Now if the author(s) respond, then i would work hard to integrate the same. After interaction with James Morris at FOSS.in, Bangalore, India, i came to know that he is also working on se-linux and he mentioned about the presence of reference policy support in LTP. I pointed him the release that i made this year (EAL4+ Certification Test Suite) and also requested him whether he can update me on the se-linux reference policy test cases of se-linux available inside Main LTP, he pointed me to write to se-linux test suite mailing list. Hence this mail. Reasonable. And it looks like the prod was needed. Now i myself has never executed these test case, so not aware of them much. But that should not prevent me from requesting updates of the same. I would be extremely happy even if we can reach the final updates through some pointer-to-pointer and that will serve my purpose of having all updates in LTP. Just to cite an example, i recently found out that there are updates being made to pounder21 test suite(present inside LTP), by somebody for his/her internal project use. Now, the same has never been updated in LTP for quite long time. I immediately mailed to him requesting him for updates. Now my purpose will be served if i get updates from him, let alone it comes to me after long time is not the question. Anyway I think there is value to having the selinux testsuite.
[LTP] [PATCH] LTP testcase mincore01 fails on SLES-9 SP4 31bit
Hi,
Please find a problem reported by Mark Ver for the mincore01 test case
in LTP. He has also provided fix for the same. Kindly review this patch:
===
Mark Reports:
===
mincore01 testcase fails with:
t75ticltst:~/ltp-full-20071031/testcases/kernel/syscalls/mincore # ./mincore01
mincore011 PASS : expected failure: errno = 22 (Invalid argument)
mincore012 FAIL : call succeeded unexpectedly
mincore013 PASS : expected failure: errno = 12 (Cannot allocate memory)
t75ticltst:~/ltp-full-20071031/testcases/kernel/syscalls/mincore #
It only happens on 31bit and seems to work on on SLES-9 SP3.
If this is not an installation problem,
Provide output from uname -a, if possible:
Linux t75ticltst 2.6.5-7.305-s390 #1 SMP Tue Nov 13 23:19:08 UTC 2007 s390 s390
s390 GNU/Linux
Hardware Environment
Machine type (p650, x235, SF2, etc.): Tested on System z9 EC and z800
Cpu type (Power4, Power5, IA-64, etc.):
Describe any special hardware you think might be relevant to this problem:
Is this reproducible? Yes
If so, how long does it (did it) take to reproduce it? 20sec - 30min
Describe the steps:
- Install SLES-9 SP4 31bit system
- Get, unpack, and compile the ltp test suite
- Run the mincore01 testcase
===
Investigation from Anoop:
===
This turned out to be a test case problem. The only way how mincore can
generate an -EFAULT on s390 is if the target buffer is an area that is not
contained in a vma. mmap()-ing with a NULL
address gives you a pointer to a piece of memory which will be the highest
address in the anonymous mapping area, if no other mmap() is done. The testcase
tries to create an invalid pointer by unmap()-ing it. But, if the stack is
unlimited (ulimit -s unlimited) and because stack vma is VM_GROWSDOWN, the
unmap()-ed pointer is part of the stack and is a valid pointer which makes the
syscall succeed. The testcase can be fixed by setting a stack limit by ulimit
-s value before its execution.
Attached is the patch which should fix this.
===
===
Regards--
Subrata,
Signed-off-by: Anoop Vijayan [EMAIL PROTECTED]
--- ltp-full-20071031/testcases/kernel/syscalls/mincore/mincore01.c.orig 2007-12-10 15:01:32.995206304 -0800
+++ ltp-full-20071031/testcases/kernel/syscalls/mincore/mincore01.c 2007-12-10 15:08:53.524235712 -0800
@@ -60,12 +60,14 @@
#include sys/mman.h
#include stdlib.h
#include unistd.h
+#include sys/resource.h
#include sys/types.h
#include sys/stat.h
#include test.h
#include usctest.h
static int PAGESIZE;
+static rlim_t STACK_LIMIT = 10485760;
static void cleanup(void);
static void setup(void);
@@ -167,13 +169,22 @@ void
setup2()
{
unsigned char *t;
-
+struct rlimit limit;
+
/* Create pointer to invalid address */
if( MAP_FAILED == (t = mmap(0,global_len,PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,0,0)) ) {
tst_brkm(TBROK,cleanup,mmaping anonymous memory failed: %s,strerror(errno));
}
munmap(t,global_len);
-
+
+/* set stack limit so that the unmaped pointer is invalid for architectures like s390 */
+limit.rlim_cur = STACK_LIMIT;
+limit.rlim_max = STACK_LIMIT;
+
+if (setrlimit(RLIMIT_STACK, limit) != 0) {
+tst_brkm(TBROK,cleanup,setrlimit failed: %s,strerror(errno));
+}
+
TC[1].addr = global_pointer;
TC[1].len = global_len;
TC[1].vector = t;
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
