On Wed, Jan 16, 2019 at 9:00 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> On Wed, Jan 16, 2019 at 8:06 AM Guenter Roeck <groeck@xxxxxxxxxx> wrote:
> >
> > On Mon, Jan 14, 2019 at 11:05 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
> > >
> > > On Mon, Jan 14, 2019 at 11:01 AM Guenter Roeck <groeck@xxxxxxxxxx> wrote:
> > > >
> > > > On Mon, Jan 14, 2019 at 10:50 AM Greg Kroah-Hartman
> > > > <gregkh@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > > > > > > ---
> > > > > > > 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
