On Wed, Jan 16, 2019 at 9:00 AM Kees Cook keescook@chromium.org wrote:
On Wed, Jan 16, 2019 at 8:06 AM Guenter Roeck groeck@google.com wrote:
On Mon, Jan 14, 2019 at 11:05 AM Kees Cook keescook@chromium.org wrote:
On Mon, Jan 14, 2019 at 11:01 AM Guenter Roeck groeck@google.com wrote:
On Mon, Jan 14, 2019 at 10:50 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Mon, Jan 14, 2019 at 10:21:45AM -0800, Guenter Roeck wrote:
On Mon, Jan 14, 2019 at 10:13 AM Gwendal Grignou gwendal@chromium.org wrote: > > Prevent an empty line in /proc/self/status, allow iotop to work. > > iotop does not like empty lines, fails with: > File "/usr/local/lib64/python2.7/site-packages/iotop/data.py", line > 196, in parse_proc_pid_status > key, value = line.split(':\t', 1) > ValueError: need more than 1 value to unpack > > [reading /proc/self/status] > > Fixes: 84964fa3e5a0 ("proc: Provide details on speculation flaw mitigations") > > Signed-off-by: Gwendal Grignou gwendal@chromium.org > --- > v2: Format commit message properly with proper subject and fixes > keyword. > You might want to mention that this patch only applies to v4.4.y. v4.9.y has a similar problem, but only if CONFIG_SECCOMP=n, and would require a slightly different patch to fix. Other releases are, as far as I can see, not affected.
Guenter
> fs/proc/array.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/proc/array.c b/fs/proc/array.c > index 0c142916a8c7d..f11df9ab4256e 100644 > --- a/fs/proc/array.c > +++ b/fs/proc/array.c > @@ -334,7 +334,7 @@ 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 > - seq_printf(m, "\nSpeculation_Store_Bypass:\t"); > + seq_printf(m, "Speculation_Store_Bypass:\t");
Why isn't this issue showing up in all kernel releases, as this line is still the same in 5.0-rc2?
What makes the 4.4.y and 4.9.y trees so special here?
v4.14 and later:
{ seq_put_decimal_ull(m, "NoNewPrivs:\t", task_no_new_privs(p)); #ifdef CONFIG_SECCOMP seq_put_decimal_ull(m, "\nSeccomp:\t", p->seccomp.mode); #endif seq_printf(m, "\nSpeculation_Store_Bypass:\t");
v4.9:
{ #ifdef CONFIG_SECCOMP seq_put_decimal_ull(m, "Seccomp:\t", p->seccomp.mode); ^^^ #endif seq_printf(m, "\nSpeculation_Store_Bypass:\t"); ^^^
-> extra newline if CONFIG_SECCOMP=n
v4.4:
{ #ifdef CONFIG_SECCOMP seq_printf(m, "Seccomp:\t%d\n", p->seccomp.mode); ^^^ #endif seq_printf(m, "\nSpeculation_Store_Bypass:\t"); ^^^
-> always extra newline
Guenter
Yeah, this grew out of odd placement of the trailing "\n". I agree it needs fixing universally.
I think we need some guidance on how to fix this problem in 4.4.y and 4.9.y. Backport more of the context patches or stable-release-only patches, possibly with more context explaining the reason ?
I think we need 4.4 and 4.9 specific patches that fix it up, and a patch to Linus that regularizes the "always have a trailing \n" style (since the mixture of newlines was what causes this problem in the first place).
Unfortunately, the lack of trailing newlines is triggered by the use of seq_put_{decimal,hex}_{ull,ll,...}(), which do not add a trailing newline, are used all over the place, and pretty much mandate the use of "\n" at the beginning of the next print statement. I don't think there is an easy way to fix that.
Guenter
-- Kees Cook