Re: [PATCH] blktrace: put bounds on BLKTRACESETUP buf_size and buf_nr

[harshad shirwadkar <harshadshirwadkar@gmail.com>]

Given that this is a kernel bug and can be exploited by any user-space
application, the fix in the kernel is a must have. But we don't want
to break any existing user-space applications. So, we do need to go
make sure that this patch doesn't break any existing applications. I
originally sent this patch assuming that blktrace is the only user of
this IOCTL. So, if anyone knows any other callers that we need to
investigate, please let me know. I have verified that these limits
don't break blktrace.

On Mon, Jun 8, 2020 at 2:59 PM Chaitanya Kulkarni
<Chaitanya.Kulkarni@wdc.com> wrote:
>
> Bart,
> On 6/8/20 7:20 AM, Bart Van Assche wrote:
> > On 2020-06-07 23:40, Chaitanya Kulkarni wrote:
> >> Bart,
> >> On 6/5/20 6:43 AM, Bart Van Assche wrote:
> >>> We typically do not implement arbitrary limits in the kernel. So I'd
> >>> prefer not to introduce any artificial limits.
> >> That is what I mentioned in [1] that we can add a check suggested in
> >> [1]. That way we will not enforce any limits in the kernel and keep
> >> the backward compatibility.
> >>
> >> Do you see any problem with the approach suggested in [1].
> >>
> >> [1]https://www.spinics.net/lists/linux-block/msg54754.html
> > Please take another look at Harshad's patch description. My
> > understanding is that Harshad wants to protect the kernel against
> > malicious user space software. Modifying the user space blktrace
> > software as proposed in [1] doesn't help at all towards the goal of
> > hardening the kernel.
> >
> > Thanks,
> >
> > Bart.
> >
>
> Hmmm, I agree that we need fix for that. What I did't understand that
> why we don't need userspace fix ?
>
> Also, what is a right way to impose these limits without having any
> bounds in kernel ?
From what I understand, there's no alternative to having a fix in the
kernel. That's because, if the kernel is not fixed and only the
commonly used user-space apps are fixed, I can always write a new
program to break the kernel. So, as mentioned above, maybe we can make
these limits configurable via sysfs but we'll need these bound checks
in the kernel.

Thanks,
Harshad
>
> Either I did not understand your comment(s) or I'm confuse.
>
> Can you please elaborate ?