[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+MmOfh2xSg6vzaK8RWYr_+tDnT=95VAKSm_4GKM0zm6A@mail.gmail.com>
Date: Sat, 3 Nov 2012 09:07:49 -0700
From: Kees Cook <keescook@...omium.org>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Will Drewry <wad@...omium.org>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Paul Gortmaker <paul.gortmaker@...driver.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v2] proc: add "Seccomp" to status
On Sat, Nov 3, 2012 at 4:51 AM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> On Thu, Nov 01, 2012 at 11:35 -0700, Kees Cook wrote:
>> @@ -327,6 +327,13 @@ static inline void task_cap(struct seq_file *m, struct task_struct *p)
>> render_cap_t(m, "CapBnd:\t", &cap_bset);
>> }
>>
>> +static inline void task_seccomp(struct seq_file *m, struct task_struct *p)
>> +{
>> +#ifdef CONFIG_SECCOMP
>> + seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode);
>> +#endif
>
> Hmm, probably it's better to always show this line, not only on
> SECCOMP'ed kernel? If it is disabled just print "0". It will simplify
> parsing of /proc/pid/status.
I disagree -- if the line is missing it means the kernel doesn't
support it, which is a different state from seccomp being inactive in
the process.
And since other things when not built into the kernel are similarly
missing from status, this is the consistent behavior for such
situations.
-Kees
--
Kees Cook
Chrome OS Security
--
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