linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	cgroups@vger.kernel.org, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH] sched/core: check format and overflows in cgroup2 cpu.max
Date: Wed, 6 Mar 2019 08:11:54 -0800	[thread overview]
Message-ID: <20190306161154.GF50184@devbig004.ftw2.facebook.com> (raw)
In-Reply-To: <4c0f1d90-b147-e1cd-20c1-0cdd869f4f15@yandex-team.ru>

Hello, Konstantin.

On Tue, Mar 05, 2019 at 08:03:24PM +0300, Konstantin Khlebnikov wrote:
> >Ditto as the blkio patch.  Unless there is a correctness problem, my
> >preference is towards keeping the parsing functions simple and I don't
> >think the kernel needs to play the role of strict input verifier here
> >as long as the only foot getting shot is the user's own.
> 
> IMHO non-strict interface more likely hides bugs and could cause
> problems for future changes.
> 
> Here is only only one fatal bug - buffer overflow in sscanf because
> %s has no limit.

Ah, indeed.  Can you please post a patch to fix that problem first?

> Strict validation could be done as more strict sscanf variant or
> some kind of extension for format string.

I don't necessarily disagree with you; however, what often ends up
with these manually crafted parsing approach are 1. code which is
unnecessarily difficult to follow 2. different subset of validations
and parsing bugs (of course) everywhere.

Given the above, I tend to lean towards dump sscanf() parsing.  If we
wanna improve the situation, I think the right thing to do is either
improving sscanf or introducing new helpers to parse these things
rather than hand-crafting each site.  It is really error-prone.

Thanks.

-- 
tejun

  reply	other threads:[~2019-03-06 16:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-27  8:13 [PATCH] sched/core: check format and overflows in cgroup2 cpu.max Konstantin Khlebnikov
2019-03-05 15:57 ` Tejun Heo
2019-03-05 17:03   ` Konstantin Khlebnikov
2019-03-06 16:11     ` Tejun Heo [this message]
2019-03-06 16:48       ` Peter Zijlstra
2019-03-06 17:21         ` Konstantin Khlebnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190306161154.GF50184@devbig004.ftw2.facebook.com \
    --to=tj@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).