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] [day] [month] [year] [list]

Message-ID: <CY1PR02MB213831731FA01F46D2713875B8170@CY1PR02MB2138.namprd02.prod.outlook.com>
Date:   Mon, 24 Sep 2018 18:26:23 +0000
From:   Jolly Shah <JOLLYS@...inx.com>
To:     Olof Johansson <olof@...om.net>
CC:     Sudeep Holla <sudeep.holla@....com>,
        "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>,
        "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 Olof,

> -----Original Message-----
> From: Olof Johansson [mailto:olof@...om.net]
> Sent: Sunday, September 23, 2018 6:11 AM
> To: Jolly Shah <JOLLYS@...inx.com>
> Cc: Sudeep Holla <sudeep.holla@....com>; ard.biesheuvel@...aro.org; Ingo
> Molnar <mingo@...nel.org>; Greg Kroah-Hartman
> <gregkh@...uxfoundation.org>; matt@...eblueprint.co.uk;
> 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,
> 
> Apologies for the slow responses here, I meant to follow up on this sooner.
> 
> On Tue, Sep 11, 2018 at 8:20 PM, Jolly Shah <JOLLYS@...inx.com> wrote:
> > Hi Sudeep and Olof,
> >
> > Clock driver from same patch set uses ioctl API along with other clock eemi
> APIs. As clock patches' final review is pending by Stephen, Michal only created
> pull request for rest of the patches and that doesn't require ioctl api. I will
> remove it and submit new patch set.
> >
> > For future patches which requires ioctl api, would like to understand your
> suggestion so I can make required changes. For zynqmp, EEMI interface allows
> clock, reset, power etc management through firmware but apart from those
> there are some operations which needs secure access through firmware.
> Examples are accessing some storage registers for inter agent communication,
> configuring another agent(RPU) mode, setting PLL parameters, boot device
> configuration etc. Those operations are covered as ioctls as they are very
> platform specific. Do you suggest to handle them with individual EEMI APIs
> instead of ioctl API?
> 
> I'm personally less worried about whether the calls are through an ioctl API or an
> EEMI one, but if it is through ioctl, I'd prefer if it wasn't wide-open pass-through.
> I.e. that the ioctls you actually use are documented, and only those who are
> whitelisted are passed through (and not in general exported to userspace).
> 
> Does that make sense?
> 

Sounds perfect. I will make required changes in next incremental patchset.

Thanks,
Jolly Shah


> 
> -Olof