linux-kernel - RE: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control

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: <CY1PR02MB2138BF2252E1CE2C1747A78AB8050@CY1PR02MB2138.namprd02.prod.outlook.com>
Date:   Mon, 10 Sep 2018 19:17:45 +0000
From:   Jolly Shah <JOLLYS@...inx.com>
To:     Olof Johansson <olof@...om.net>
CC:     "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        Ingo Molnar <mingo@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "matt@...eblueprint.co.uk" <matt@...eblueprint.co.uk>,
        Sudeep Holla <sudeep.holla@....com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        Kees Cook <keescook@...omium.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Michal Simek <michals@...inx.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        linux-clk <linux-clk@...r.kernel.org>,
        Rajan Vaja <RAJANV@...inx.com>,
        Linux ARM Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>
Subject: RE: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for
 device control

Hi All,

Adding more clarification on top of what Michal said:
Here ioctl is not a system ioctl and just a eemi API like other interface APIs. It cannot be called from userspace. Only Linux drivers can use this API for defined ioctl operations. This API is meant for any platform specific operations which needs to be managed by firmware. Firmware will always validate the request for action being performed.
Debugfs interface is just for debugging during development. We can remove debugfs support for ioctl API if you suggest.

Thanks,
Jolly Shah


> -----Original Message-----
> From: Olof Johansson [mailto:olof@...om.net]
> Sent: Saturday, September 08, 2018 6:19 PM
> To: Jolly Shah <JOLLYS@...inx.com>
> Cc: ard.biesheuvel@...aro.org; Ingo Molnar <mingo@...nel.org>; Greg Kroah-
> Hartman <gregkh@...uxfoundation.org>; matt@...eblueprint.co.uk; Sudeep
> Holla <sudeep.holla@....com>; hkallweit1@...il.com; Kees Cook
> <keescook@...omium.org>; Dmitry Torokhov <dmitry.torokhov@...il.com>;
> Michael Turquette <mturquette@...libre.com>; Stephen Boyd
> <sboyd@...eaurora.org>; Michal Simek <michals@...inx.com>; Rob Herring
> <robh+dt@...nel.org>; Mark Rutland <mark.rutland@....com>; linux-clk
> <linux-clk@...r.kernel.org>; Rajan Vaja <RAJANV@...inx.com>; Linux ARM
> Mailing List <linux-arm-kernel@...ts.infradead.org>; Linux Kernel Mailing List
> <linux-kernel@...r.kernel.org>; DTML <devicetree@...r.kernel.org>; Jolly
> Shah <JOLLYS@...inx.com>
> Subject: Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for
> device control
> 
> Hi,
> 
> On Fri, Aug 3, 2018 at 10:53 AM, Jolly Shah <jolly.shah@...inx.com> wrote:
> > From: Rajan Vaja <rajanv@...inx.com>
> >
> > Add ZynqMP firmware IOCTL API to control and configure devices like
> > PLLs, SD, Gem, etc.
> >
> > Signed-off-by: Rajan Vaja <rajanv@...inx.com>
> > Signed-off-by: Jolly Shah <jollys@...inx.com>
> 
> This patch worries me somewhat. It's a transparent pass-through ioctl driver. Is
> there a spec available for what the implemented IOCTLs are?
> 
> Should some of them be proper drivers instead of an opaque pass-through like
> this? Could some of them have stability impact on the platform such that there
> are security concerns and the list of arguments should somehow be sanitized?
> 
> What's the intended usecase anyway? Just a debug tool during development, or
> something that you expect heavy use of by some userspace middleware?
> 
> 
> -Olof