linux-kernel - Re: [PATCH v3 2/4] bus: fsl-mc: add fsl-mc userspace support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181121081418.GD8162@kroah.com>
Date:   Wed, 21 Nov 2018 09:14:18 +0100
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Ioana Ciornei <ioana.ciornei@....com>
Cc:     Laurentiu Tudor <laurentiu.tudor@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev-owner@...r.kernel.org" <netdev-owner@...r.kernel.org>,
        Ioana Ciocoi Radulescu <ruxandra.radulescu@....com>,
        Horia Geanta <horia.geanta@....com>,
        Leo Li <leoyang.li@....com>
Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add fsl-mc userspace support

On Tue, Nov 20, 2018 at 05:59:26PM +0000, Ioana Ciornei wrote:
> > > +static int fsl_mc_uapi_send_command(unsigned long arg,
> > > +				    struct fsl_mc_io *mc_io)
> > > +{
> > > +	struct fsl_mc_command mc_cmd;
> > > +	int error;
> > > +
> > > +	error = copy_from_user(&mc_cmd, (void __user *)arg, sizeof(mc_cmd));
> > > +	if (error)
> > > +		return -EFAULT;
> > > +
> > > +	error = mc_send_command(mc_io, &mc_cmd);
> > > +	if (error)
> > > +		return error;
> > > +
> > > +	error = copy_to_user((void __user *)arg, &mc_cmd, sizeof(mc_cmd));
> > > +	if (error)
> > > +		return -EFAULT;
> > > +
> > > +	return 0;
> > > +}
> > 
> > I know you said that "the firmware will properly verify the command"
> > already, but given that I used to be a firmware developer a long time ago, I can
> > almost guarantee that this will cause problems in the future.
> > 
> > Want to make a friendly bet about this?
> > 
> > What is the odds that your firmware api/interface has been properly fuzzed such
> > that all possible combinations of bad commands will really not do horrible things
> > to the hardware/system?
> > 
> > Are you all willing to bet the system intregrity on this?  If so, ok, it's your systems
> > :)
> > 
> > Personally, I think you need to add a "known whitelist" and do some sort of
> > sanity checking here.
> > 
> 
> I can add a whitelist on the command ids that can be received from userspace but
> leave the parameter parsing to the firmware to process and interpret depending on the
> current system settings.
> 
> Would that be a viable option from your point of view?

That might be a good start.  Again, how well have you tested this
firmware interface can handle invalid data?  Are you willing to bet your
system integrity on it?  :)

thanks,

greg k-h