[] 0x
Below patch fixes this warning, but is simpler fix
- char options[] = "mode=0755";
+ static char options[PAGE_SIZE] = "mode=0755";
better?
>From 4e768f2e7ea75786a69baae52469e1662244d933 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: We
gt;From 8d4d6df4d112c1b38bf880a3a63d0336c9b7d0e3 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 14 May 2013 16:32:05 +0900
Subject: [PATCH] mm: Fix kmemcheck warning.
Some field of "struct anon_vma" and "struct anon_vma_chain" are not
initialized, resulting kmemcheck w
I got below warning. The problem might be in SLUB code.
WARNING: kmemcheck: Caught 64-bit read from freed memory (88007a1297a0)
6098127a00880100c0c6fe7900880800
f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f
^
RIP: 0010:[] [] __kmal
Adding kmemcheck maintainer, for this might be false positives.
Regarding https://lkml.org/lkml/2013/5/14/248 (this thread) and
https://lkml.org/lkml/2013/5/14/250 (similar one), I tried to run bisection,
but I couldn\'t find the culprit. This problem seems to exist at least since
Linux 3.6. (I co
Christoph Lameter wrote:
> On Tue, 30 Apr 2013, Tetsuo Handa wrote:
>
> > The testcases still trigger BUG() at 32M:
>
> I thought we established that MAX_ORDER only allows a maximum of 8M sized
> allocations? Why are you trying 32M?
Only for regression testing. At
Christoph Lameter wrote:
> > "kmalloc() returning NULL for these allocations" is needed by "try kmalloc()
> > first, fallback to vmalloc()" allocation. There are kernel modules which
> > expect
> > kmalloc() to return NULL rather than oops when the requested size is larger
> > than KMALLOC_MAX_SIZ
Tetsuo Handa wrote:
> > Hmm... Where does this fail? In slab?
> >
> It hangs (with CPU#0 spinning) immediately after printing
>
> Decompressing Linux... Parsing ELF... done.
> Booting the kernel.
>
> lines. Today I heard that gdb can be used if I use qemu, but
Christoph Lameter wrote:
> I have booted such a configuration just fine. Please have a look at the
> kernel config that I send or send me yours.
OK. Here are complete steps to reproduce using QEMU on CentOS 6.4.
(1) Compile the kernel for x86_32 and run it on QEMU.
$ cd /tmp/
$ wget -O -
ht
Applying
Subject: slab: Return NULL for oversized allocations
(Date: Fri, 3 May 2013 15:43:18 +)
and
Subject: Fix bootstrap creation of kmalloc caches
(Date: Fri, 3 May 2013 18:04:18 +)
on linux-next-20130426 made my kernel boots fine and passes the allocation
testcases. Thank y
Christoph Lameter wrote:
> Ok could I see the kernel logs with the warnings?
Sure.
-- testcase --
volatile unsigned int size;
for (size = 4 * 1024 * 1024; size <= 32 * 1024 * 1024; size <<= 1) {
void *ptr = kmalloc(size, GFP_KERNEL);
printk("kmalloc(%u)=%p\n", size,
Christoph Lameter wrote:
> On Sat, 4 May 2013, Tetsuo Handa wrote:
>
> > Christoph Lameter wrote:
> > > Ok could I see the kernel logs with the warnings?
> > Sure.
>
> These are exclusively from the module load. So the kernel seems to be
> clean of large k
Chris Mason wrote:
> Commit 8a965b3b introduced a regression that caused us to crash early
> during boot. The commit was introducing ordering of slab creation,
> making sure two odd-sized slabs were created after specific powers of
> two sizes.
>
> But, if any of the power of two slabs were crea
Tetsuo Handa wrote:
> > Christoph Lameter wrote:
> > > What is MAX_ORDER on the architecture?
> >
> > In my environment (x86_32), the constants are
> >
> > MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304
> >
>
&g
Christoph Lameter wrote:
> - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) {
> + for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) {
mm/slab.c: In function 'init_node_lock_keys':
mm/slab.c:568:17: error: expected expression before '<' token
What I'm worrying is:
/*
* The largest kmalloc
Tetsuo Handa wrote:
> Can we manage with allocating only 26 elements when MAX_ORDER + PAGE_SHIFT >
> 26
> (e.g. PAGE_SIZE == 256 * 1024) ?
>
> Can kmalloc_index()/kmalloc_size()/kmalloc_slab() etc. work correctly when
> MAX_ORDER + PAGE_SHIFT > 26 (e.g. PAGE_SIZE ==
Hello.
linux-next-20130422 does not boot when built with CONFIG_DEBUG_SLAB=y &&
CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y .
It hangs (with CPU#0 spinning) immediately after printing
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
lines.
Config is at http://I-love.
James Hogan wrote:
> How does the patch below look? I presume this is preferred over
> making VMLINUX_SYMBOL_STR non-argument-expanding?
>
> Thanks
> James
>
> Subject: [PATCH 1/1] modpost: fix unwanted VMLINUX_SYMBOL_STR expansion
>
> Commit a4b6a77b77ba4f526392612c2365797fab956014 ("module: fi
Tetsuo Handa wrote:
> Hello.
>
> linux-next-20130422 does not boot when built with CONFIG_DEBUG_SLAB=y &&
> CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y .
>
> It hangs (with CPU#0 spinning) immediately after printing
>
> Decompressing Linux
Casey Schaufler wrote:
> >> I'm still in favor of assigning the network hooks to the LSM at boot based
> >> on
> >> the "security=" configuration.
> >>
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
>
> I'll have a go at it then
Tetsuo Handa wrote:
> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26.
>
> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and
> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case
> happens), kmalloc_caches[26] is beyond the array
Glauber Costa wrote:
> If I am right, the following (untested) patch should solve the problem.
This patch did not help;
kmalloc(8 * 1024 * 1024, GFP_KERNEL)
still causes both
include/linux/slab_def.h:136: warning: array subscript is above array bounds
and
BUG: unable to handle kernel NU
Tetsuo Handa wrote:
> Glauber Costa wrote:
> > If I am right, the following (untested) patch should solve the problem.
>
> This patch did not help;
>
> kmalloc(8 * 1024 * 1024, GFP_KERNEL)
>
> still causes both
>
> include/linux/slab_def.h:136: warnin
Christoph Lameter wrote:
> Ok so the maximum allocation is 11+12=23 which is 8M. KMALLOC_MAX_SIZE
> amd KMALLOC_SHIFT_HIGH are wrong.
>
> Take the -1 off the constants under #ifdef CONFIG_SLAB in
Current diff is:
-- patch start --
diff --git a/include/linux/slab.h b/include/linux
Fernando Luis V痙quez Cao wrote:
> (Moving discussion to LKML)
>
> Hi Thomas, Frederic,
>
> Tetsuo Handa reported that the iowait time obtained through /proc/stat
> is not monotonic.
>
Hello.
The following instructions are steps for observing this problem.
It is recomme
Dave Hansen wrote:
> I have reproduced this bug and this patch fixes it for me
>
> https://lkml.org/lkml/2013/2/5/396
>
> Signed-off-by: Dave Hansen
This patch fixes it for me too.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
Dave Hansen wrote:
>
> The original bug reporter says this fixes it for him, so I'm
> broadening the cc list a bit. I assume this should just get
> sucked in to the x86 tree.
>
> The double-signed-off-by from my is because my IBM email is
> going away very shortly.
>
> --
>
> kernel_map_sync_m
Hello.
Under unknown condition, clock starts counting up too quickly which is enough
to confuse hangcheck timer to print stall warning.
I don't know the condition but it seems that
"[sched_delayed] sched: RT throttling activated" message is printed
when time jump starts and the CPU usage is high
Hello.
Tetsuo Handa wrote:
> Under unknown condition, clock starts counting up too quickly which is enough
> to confuse hangcheck timer to print stall warning.
I wrote a test program.
-- test program start --
#include
#include
#include
int main(int argc, char
Tetsuo Handa wrote:
> > Under unknown condition, clock starts counting up too quickly which is
> > enough
> > to confuse hangcheck timer to print stall warning.
> I wrote a test program.
I suspected that this is a problem within adjtimex() because strace reported
clock
ju
Hello.
Bisected to 2a8c0883 "time: Move xtime_nsec adjustment underflow handling
timekeeping_adjust".
Would you check?
Regards.
Tetsuo Handa wrote:
> Tetsuo Handa wrote:
> > > Under unknown condition, clock starts counting up too quickly which is
> > > enough
&
Ingo Molnar wrote:
> > Bisected to 2a8c0883 "time: Move xtime_nsec adjustment
> > underflow handling timekeeping_adjust".
> >
> > Would you check?
>
> probably caused by this stray return in timekeeping_adjust():
>
> } else
> return;
>
> which should really be a proper
Hello.
I'm experiencing two regressions in 3.8-rcX.
Regression:
(1) Console shows nothing, which makes it impossible to determine whether
the system is working or not.
(2) SCSI_SYM53C8XX_2 cannot register IRQ, showing below messages upon load.
PCI: enabling device :00:0c.0
Linus Walleij wrote:
> > While (1) was fixed by now, I can't bisect (2) since (1) is preventing (2)
> > from
> > printing messages.
>
> I usually bisect like this:
>
> 1. Get hold of the patch fixing the boot regression:
> git format-patch
> f5565295892eb93c3191aa241405fe8b685542d6^..f55652
Linus Walleij wrote:
> > Which one ("blank console bug" or "IRQ registration failure bug") does
> > "the boot regression" refer?
>
> They are likely one and the same bug? The only regression on
> the versatile I have caused came from commit
> f5565295892eb93c3191aa241405fe8b685542d6.
>
It seems t
>From af0876644f04eca9d59c96320447abb0af526079 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 16 Oct 2012 22:30:38 +0900
Subject: [PATCH 3.7-rc1] Fix kconfig failure on old environments.
Commit 95ac9b3b "menuconfig: Assign jump keys per-page instead of globally"
used mac
P J P wrote:
>
>Hello Kees, all,
>
> Please have a look at a *NEW* patch at the end of this mail. It seems to fix
> both the issues, stack disclosure + undue recursions.
>
> It uses modprobe "--first-time" option which returns an error code when
> trying
> to load a module which is alread
Tetsuo Handa wrote:
> Linux 3.6 builds fine. I can't use "git bisect" until Linux 3.7-rc6 but
> possibly caused by either commit 10b63956 "UAPI: Plumb the UAPI Kbuilds into
> the user header installation and checking" or commit 40f1d4c2 "UAPI: Remove
>
Eric Paris wrote:
> On Fri, 2013-01-11 at 00:14 +0900, Tetsuo Handa wrote:
> > The reason I think is that people turn off LSMs because they are using LSMs
> > without understanding "what the current configuration is" and/or "how to
> > change
> > conf
y, 2.6.25-rc3 seems to not doing the condition check.
Is the field bprm->argv_len no longer needed?
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
fs/exec.c |3 ---
include/linux/binfmts.h |1 -
2 files changed, 4 deletions(-)
--- linux-2.6.25-rc3.orig/fs/exec.c
+++
Alex Shi wrote:
> Thanks for your report, mm should means mm_struct. no vma. My fault.
> Could you like try this patch.
Builds OK. Thank you.
> From 97781231b130e7f7fced12244653ed9b9946c944 Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Fri, 6 Jul 2012 20:49:25 +0800
> Subject: [PATCH] x86/tl
John Johansen wrote:
> On 01/09/2013 05:28 AM, James Morris wrote:
> > On Tue, 8 Jan 2013, John Johansen wrote:
> >
> >>> I'd say we need to see the actual use-case for Smack and Apparmor being
> >>> used together, along with at least one major distro committing to support
> >>> this.
> >>>
> >>
Eric Paris wrote:
> On systems with a strict security policy worried about such things this
> would quite reasonably need to be disabled. But most of the reason
> people turn off LSMs is because it gets in the way and they get pissed
> getting an EPERM, checking rwx bits, having no idea WTF happen
Message to the moderators of this ML.
Please don't forward this mail to this ML.
I intendedly mailed using a non-subscriber's address
so that this mail only seen to the moderators.
-
Hello,
I found X-OUTRCPT-TO: header since
Linux-kernel-daily-digest Dige
Hello, Matt.
> I had a note from you that this was a configuration error on your
> server's part, not on the list. So I stopped worrying about it...
Oh, really? I'm sorry.
What is funny is that ...
The mail from Matt had a X-OUTRCPT-TO header
with 2 mail addresses (my address and this ml's addr
1.tmp /dev/sda2 or unlink /dev/null; touch /dev/null ).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
--
Hello.
Willy Tarreau wrote:
> Your patch is very confusing. In your description, as well as in the
> comments you talk about tmpfs, but your patch does not touch even one
> line of tmpfs and only changes ramfs. Even your variables and arguments
> refer to tmpfs. The Kconfig entry indicates that th
ttributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
fs/Kconfig | 18 +
include/linux/shmem_fs.h |5
mm/shmem.c | 124 +++
mm/shmem_mac.h | 57 +
mm/shmem_mac_debug.c | 183 +
Hello.
[EMAIL PROTECTED] wrote:
> Ouch. The .c files should generally be built into their own .o files and
> then the Makefile should do something like
>
> obj-$(CONFIG_SYAORAN) += syaoran.o
>
> unless there's *really* good reasons for including .c files (such as an
> otherwise-messy variable-n
Hello.
Indan Zupancic wrote:
> > I want to use this filesystem in case where a process with root privilege
> > was
> > hijacked but the behavior of the hijacked process is still restricted by
> > MAC.
>
> 1) If the behaviour can be controlled, why can't the process be
>disallowed to change
Hello.
Christoph Hellwig wrote:
> Just FYI: A NACK to such an addition doesn't simply go away by
> ignoring it.
Excuse me. What NACK is remaining?
About the below comments?
> > NACK to this. Passing function parameters through the task_struct is
> > definitely not an acceptable hack
>
> Exactly
Hello.
Indan Zupancic wrote:
> I think you focus too much on your way of enforcing filename/attributes
> pairs.
So?
> The same can be achieved by creating the device nodes with
> expected attributes, and preventing processes from changing those files.
The device nodes have to be deletable if some
Hello.
[EMAIL PROTECTED] wrote:
> Good summary - probably should add that to the patch, drop it into
> Documentation/syaoran-config.txt or similar...
I see.
> Modification while reading *is* an issue, but can probably be worked around
> with some clever locking. The race condition I was thinking
Hello.
Brent Casavant wrote:
> However, the program would occasionally get into a situation where
> a call to recv(sockfd, &buf, len, MSG_PEEK) returns some number
> of bytes less than the requested length, and persists in this state
> (i.e. retrying the call continues to return the same amount of
Hello.
Indan Zupancic wrote:
> Good point, but I assume they all have at least a directory granularity, and
> then
> /dev/ can be static and udev and other can have free reign in e.g.
> /dev/dynamic/.
> Just use subdirs for the dynamic stuff and this granularity problem is, with
> slight inconve
Hello.
I found that
CONFIG_BLK_DEV_RAM=m
in my .config makes
#ifdef CONFIG_BLK_DEV_RAM
false.
I guess something is wrong with .config parsing.
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo in
Hello.
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> I don't think that this is a change from the recent past.
Oh, it is my mistake.
I found that choosing CONFIG_BLK_DEV_RAM=m makes
impossible to pass an initrd image since
populate_rootfs() in init/initramfs.c omits
code for checking whether the ima
is a side effect or not.
Should we use "X" rather than "\\"?
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
scripts/checkpatch.pl |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- linux-2.6-mm.orig/scripts/checkpatch.pl
+++ linux-2.6-mm
Tetsuo Handa wrote:
> checkpatch.pl was unable to handle \\ within quoted string.
Sorry, I didn't know checkpatch 0.13 is available.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More major
Hello.
Thank you for your comment.
James Morris wrote:
> Why do you need to avoid spinlocks for these manipulations?
I don't need to use spinlocks here.
What I need to do here is avoid read/write reordering,
so mb() will be appropriate here.
struct something {
struct something *next;
void *
Hello.
James Morris wrote:
> Why do you need racy unlocked versions, in addition to the existing
> security_task_kill() hook which is called safely via
> check_kill_permission() ?
TOMOYO Linux provides "delayed enforcing mode" which allows administrator
judge interactively for requests that vio
Hello.
Thank you for your comment.
James Morris wrote:
> I'm guessing you need this to determine the receiving process, rather than
> the socket (which is available via security_sock_rcv_skb()).
Use of security_sock_rcv_skb() was discussed at
http://lkml.org/lkml/2007/8/28/74 ,
and answer is at
Hello.
James Morris wrote:
> Would you please explain why you need another level of memory allocation?
>
> What does it do apart from let you check for memory leaks?
Difference between tmy_alloc() and kmalloc() are
tmy_alloc() allows administrator know "how much memory is used by TOMOYO
Linu
Hello.
YOSHIFUJI Hideaki wrote:
> Introducing your own list is not good.
> Please use hlist or introduce new "slist".
James Morris wrote:
> You're introducing a custom API, which is open-coded repeatedly throughout
> your module.
>
> All linked lists (at least, new ones) must use the standard k
James Morris wrote:
> I'm pretty sure that the singly linked list idea has been rejected a few
> times. Just use the existing API.
Too bad...
Well, is there a way to avoid read_lock when reading list?
Currently, TOMOYO Linux avoids read_lock, on the assumption that
(1) First, ptr->next is init
Hello.
Thank you for pointing out.
Peter Zijlstra wrote:
> > Currently, TOMOYO Linux avoids read_lock, on the assumption that
> > (1) First, ptr->next is initialized with NULL.
> > (2) Later, ptr->next is assigned non-NULL address.
> > (3) Assigning to ptr->next is done atomically.
> (4) wmb aft
Hello.
KaiGai Kohei wrote:
> If so, you can apply RCU instead to avoid read lock
> when scanning the list, like:
>
> rcu_read_lock();
> list_for_each_entry(...) {
>
> }
> rcu_read_unlock();
Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
As far as I saw, rcu_read_lock() mak
Peter Zijlstra wrote:
> Also, how do you avoid referencing dead data with your sll? I haven't
> actually looked at your patches, but the simple scheme you outlined
> didn't handle the iteration + concurrent removal scenario:
Regarding my singly-linked list, no entries are removed from the list. It
Hello.
YOSHIFUJI Hideaki wrote:
> It is not a good practice. Please free such objects.
> BTW, how many objects do you have in the list?
It varies from 0 to some thousands,
depending on the policy supplied by the administrator and/or the policy
appended by "learning mode".
Peter Zijlstra wrote
About use of singly-linked list:
What my SLL (singly-linked list) holds is bit different from other lists.
Almost all lists hold list of elements (e.g. buffer) that are used
*temporarily*.
Thus, adding to the list and removing from the list are essential.
My SLL holds ACL (access control list)
Hello.
Peter Zijlstra wrote:
> > Can I sleep between rcu_read_lock() and rcu_read_unlock() ?
> > As far as I saw, rcu_read_lock() makes in_atomic() true, so I think I can't
> > sleep.
> You can indeed not sleep in an rcu_read_lock() section. However, you
> could grab a reference on an item, stop
Hello.
Thank you for pointing out.
Jun WANG wrote:
> >rcu_read_lock();
> >list_for_each_rcu(p, ...) {
> > ptr = list_entry(p, struct ..., list);
> > /* Grab a reference to "ptr". */
> > rcu_read_unlock();
> > my_task_that_may_sleep(ptr);
> > rcu_read_lock();
> > /* Drop a reference to
Hello.
Jun WANG wrote:
> I'm sorry,I think I got your idea, if you do not need ptr in
> my_task_that_may_sleep(), why you need to grab a reference to "ptr". If
> your my_task_that_may_sleep() needs ptr, and according to the
> "memory region pointed by "ptr" never be removed." you say,
> it is ok
Hello.
Peter Zijlstra wrote:
> > So, I don't need to grab a reference to "ptr"
> > because memory region pointed by "ptr" will never be kfree()ed.
> > And it is legal to use "ptr" after rcu_read_unlock()
> > because memory region pointed by "ptr" will never be kfree()ed.
>
> Still think that is a
"TOMOYO Linux" is our work in the field of security enhanced Linux.
This is the fourth submission of TOMOYO Linux
( http://lkml.org/lkml/2007/10/2/170 ).
Thank you very much for feedbacks on previous submission.
We followed the following comments and now submitting again.
* Replace "struct semap
TOMOYO Linux uses pathnames for auditing and controlling file access.
Therefore, namespace_sem is needed.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
fs/namespace.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-
Data structures and prototype defitions for TOMOYO Linux.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/include/realpath.h | 43 +++
security/tomoyo/include/tomoyo.h | 513 ++
Basic functions to get canonicalized absolute pathnames
for TOMOYO Linux. Even the requested pathname is symlink()ed
or chroot()ed, TOMOYO Linux uses the original pathname.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
sec
tored in task_struct->security.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/domain.c | 1259 +++
1 file changed, 1259 insertions(+)
--- /dev/null 1970-01-01 00:00:00.000
e not granted in the TOMOYO Linux policy.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
include/linux/audit.h |3 ++
security/tomoyo/audit.c | 68
2 files changed, 71 insertion
ned-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/file.c | 1551 +
1 file changed, 1551 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6/security/to
t;
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/exec.c | 214 +
1 file changed, 214 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6/security/tomoyo/exec.c2007-10-11 15:53:12.
DP connect' are not checked.
Each permission can be automatically accumulated into
the policy of each domain using 'learning mode'.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTEC
rning mode'.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/mount.c | 1010
1 file changed, 1010 insertions(+)
--- /dev/null 1970-01-01 00:00:00.000
impler and "namespace_sem" can remain "static".
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/tomoyo/tomoyo.c | 600 +++
1 file changed, 600 inser
This patch allows administrators use conditional permission.
TOMOYO Linux supports conditional permission based on
process's UID,GID etc. and/or requested pathname's UID/GID.
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
Kconfig and Makefile for TOMOYO Linux.
TOMOYO Linux is placed in security/tomoyo .
Signed-off-by: Kentaro Takeda <[EMAIL PROTECTED]>
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
security/Kconfig |1 +
security/Makefile|1 +
security/tomoyo/Kco
Hello.
I encountered a BUG().
I didn't encounter this bug for 2.6.24-rc5-mm1 .
I guess this bug was introduced between 2.6.24-rc5-mm1 and 2.6.24-rc6-mm1 .
I placed .config at http://I-love.SAKURA.ne.jp/tmp/config-2.6.24-rc6-mm1
The dmesg is attached below.
Regards.
-
Linux version 2.6.24-rc6
touch /dev/null ).
This time, I'm implementing this filesystem as an extension to tmpfs
because what this filesystem does are nothing but check filename and
its attributes in addition to what tmpfs does.
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
fs/ramfs/inode.c |
Hello.
Ingo Molnar wrote:
> does the patch below help?
Yes, it solved this bug.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the F
Hello.
Serge E. Hallyn wrote:
> I apologize if I'm commiting a faux pas by asking this, but any chance
> of renaming this to something like strictdev or sdev, or at least with
> 'dev' in it somewhere?
You are not commiting a faux pas. But, this naming is my personal feeling. ;-)
You can see the o
ee necessary and sufficient permissions
for each administrative task.
You can deploy custom authentication at the entry point of each subtree
so that one administrator cannot proceed to other administrator's subtrees.
And more...
Your imagination invents new usage.
Authors:
Tetsuo Handa <
Hello.
Thank you for feedback.
Serge E. Hallyn wrote:
> > TOMOYO Linux is a DIY tool for understanding and protecting your system.
> > TOMOYO Linux policy definitions are absolutely readable to Linux users, and
> > TOMOYO Linux supports unique policy learning mechanism which automatically
>
> Ar
Hello.
Serge E. Hallyn wrote:
> Auto-learning in itself doesn't seem novel, but so you're saying it's
> novel in ust how integrated it is - no mnual intervention necessary?
You can run your system with only policy collected by learning mode.
Thus, you basically don't need manual intervention.
Bu
Hello.
Serge E. Hallyn wrote:
> > > > * namespace manipulation. (i.e. mount()/umount()/pivot_root())
> > >
> > > do you track mounts namespace cloning?
> > >
> > Yes. TOMOYO can recognize mount operation with the following flags.
> >
> > --bind --move --remount
> > --make-unbindable --mak
Hello.
[EMAIL PROTECTED] wrote:
> Please make a *big* notation someplace that "learning mode" is quite likely to
> *not* produce a totally correct policy. In particular, it won't build rules
> for
> infrequently used code paths (such as error handling) unless you find a way to
> exercise those p
Hello.
Serge E. Hallyn wrote:
> > Does a process get different mount trees by just calling clone() or
> > unshare()?
> > My understanding is that clone() or unshare() disables propergation of
> > mount tree changes when somebody calls mount() or umount() or pivot_root().
>
> Yes, with further pr
Hello.
Thank you for reviewing.
Serge E. Hallyn wrote:
> > This time, I'm implementing this filesystem as an extension to tmpfs
> > because what this filesystem does are nothing but check filename and
> > its attributes in addition to what tmpfs does.
>
> To integrate this nicer into tmpfs, at l
mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know why.
Signed-off-by: Tetsuo Handa <[EMAIL PROTECTED]>
---
mm/slab.c |1 +
mm/slob.c |1 +
2 files changed, 2 insertions(+)
--- linux-2.6-mm.orig/mm/slab.c
+++ linux-2.6-mm/mm/slab.c
@@ -4479,3 +
Hello.
I can't pass memory allocated by kmalloc() to ksize()
if it is allocated by SLUB allocator and
size is larger than (I guess) PAGE_SIZE / 2.
Regards.
-- Kernel config (grep CONFIG_SLUB .config) --
CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
# CONFIG_SLUB_DEBUG_ON is not set
Hello.
Adrian Bunk wrote:
> > mm/slub.c exports ksize(), but mm/slob.c and mm/slab.c don't. I don't know
> > why.
> That's due to the fact that my patch to remove this unused export from
> slub was not yet applied...
So, removing exports is intended thing?
> Where is the modular in-kernel user?
101 - 200 of 2177 matches
Mail list logo
