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@xxxxxxx> 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 ?