linux-kernel - Re: [RFC patch 15/20] LTTng Kernel Trace Thread Flag SH

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 10 May 2009 02:15:51 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	akpm@...ux-foundation.org, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, "Frank Ch. Eigler" <fche@...hat.com>,
	Jason Baron <jbaron@...hat.com>,
	Tom Zanussi <tzanussi@...il.com>, fweisbec@...il.com,
	laijs@...fujitsu.com, rostedt@...dmis.org, peterz@...radead.org,
	jiayingz@...gle.com, roland@...hat.com, mbligh@...gle.com
Subject: Re: [RFC patch 15/20] LTTng Kernel Trace Thread Flag SH

On Sat, May 09, 2009 at 12:22:24PM -0400, Mathieu Desnoyers wrote:
> Index: linux-2.6-lttng/arch/sh/include/asm/thread_info.h
> ===================================================================
> --- linux-2.6-lttng.orig/arch/sh/include/asm/thread_info.h	2009-03-15 15:57:04.000000000 -0400
> +++ linux-2.6-lttng/arch/sh/include/asm/thread_info.h	2009-03-15 15:57:17.000000000 -0400
> @@ -116,6 +116,7 @@ extern void free_thread_info(struct thre
>  #define TIF_SYSCALL_AUDIT	5	/* syscall auditing active */
>  #define TIF_SECCOMP		6	/* secure computing */
>  #define TIF_NOTIFY_RESUME	7	/* callback before returning to user */
> +#define TIF_KERNEL_TRACE	8	/* kernel trace active */
>  #define TIF_USEDFPU		16	/* FPU was used by this task this quantum (SMP) */
>  #define TIF_POLLING_NRFLAG	17	/* true if poll_idle() is polling TIF_NEED_RESCHED */
>  #define TIF_MEMDIE		18
> @@ -129,6 +130,7 @@ extern void free_thread_info(struct thre
>  #define _TIF_SYSCALL_AUDIT	(1 << TIF_SYSCALL_AUDIT)
>  #define _TIF_SECCOMP		(1 << TIF_SECCOMP)
>  #define _TIF_NOTIFY_RESUME	(1 << TIF_NOTIFY_RESUME)
> +#define _TIF_KERNEL_TRACE	(1 << TIF_KERNEL_TRACE)
>  #define _TIF_USEDFPU		(1 << TIF_USEDFPU)
>  #define _TIF_POLLING_NRFLAG	(1 << TIF_POLLING_NRFLAG)
>  #define _TIF_FREEZE		(1 << TIF_FREEZE)
> @@ -141,17 +143,19 @@ extern void free_thread_info(struct thre
>  
>  /* work to do in syscall trace */
>  #define _TIF_WORK_SYSCALL_MASK	(_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP | \
> -				 _TIF_SYSCALL_AUDIT | _TIF_SECCOMP)
> +				 _TIF_SYSCALL_AUDIT | _TIF_SECCOMP | \
> +				 _TIF_KERNEL_TRACE)
>  
>  /* work to do on any return to u-space */
>  #define _TIF_ALLWORK_MASK	(_TIF_SYSCALL_TRACE | _TIF_SIGPENDING      | \
>  				 _TIF_NEED_RESCHED  | _TIF_SYSCALL_AUDIT   | \
>  				 _TIF_SINGLESTEP    | _TIF_RESTORE_SIGMASK | \
> -				 _TIF_NOTIFY_RESUME)
> +				 _TIF_NOTIFY_RESUME | _TIF_KERNEL_TRACE)
>  
>  /* work to do on interrupt/exception return */
>  #define _TIF_WORK_MASK		(_TIF_ALLWORK_MASK & ~(_TIF_SYSCALL_TRACE | \
> -				 _TIF_SYSCALL_AUDIT | _TIF_SINGLESTEP))
> +				 _TIF_SYSCALL_AUDIT | _TIF_SINGLESTEP | \
> +				 _TIF_KERNEL_TRACE))
>  
>  #endif /* __KERNEL__ */
>  
I think you missed the comment above this hunk in the code..

This will blow up immediately, _TIF_ALLWORK_MASK must presently fit
within a byte, as it just happens to right now. If this can take the
place of _TIF_SYSCALL_TRACE in the future, then that bit position can be
used instead, otherwise the assembly code will have to be rewritten to
load a larger value, which means we lose the ability to load the mask as
an immediate without resorting to shifting and masking :-(

Other platforms have similar constraints, have you verified that this is
not a problem on any of the other platforms?

I'll of course rewrite the assembly if we can't avoid it.
--
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/