linux-kernel - Re: [PATCH v10 10/26] gunyah: vm_mgr: Introduce basic VM Manager

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]

Date:   Tue, 28 Feb 2023 10:19:00 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Alex Elder" <alex.elder@...aro.org>,
        "Elliot Berman" <quic_eberman@...cinc.com>,
        "Srinivas Kandagatla" <srinivas.kandagatla@...aro.org>,
        "Alex Elder" <elder@...aro.org>,
        "Jonathan Corbet" <corbet@....net>,
        "Prakruthi Deepak Heragu" <quic_pheragu@...cinc.com>
Cc:     "Murali Nalajala" <quic_mnalajal@...cinc.com>,
        "Trilok Soni" <quic_tsoni@...cinc.com>,
        "Srivatsa Vaddagiri" <quic_svaddagi@...cinc.com>,
        "Carl van Schaik" <quic_cvanscha@...cinc.com>,
        "Dmitry Baryshkov" <dmitry.baryshkov@...aro.org>,
        "Bjorn Andersson" <andersson@...nel.org>,
        "Konrad Dybcio" <konrad.dybcio@...aro.org>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        "Bagas Sanjaya" <bagasdotme@...il.com>,
        "Catalin Marinas" <catalin.marinas@....com>,
        "Jassi Brar" <jassisinghbrar@...il.com>,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v10 10/26] gunyah: vm_mgr: Introduce basic VM Manager

On Tue, Feb 28, 2023, at 02:06, Alex Elder wrote:
> On 2/24/23 4:48 PM, Elliot Berman wrote:
>> I'd be open to making GH_CREATE_VM take a struct argument today, but I 
>> really don't know what size or what needs to be in that struct. My hope 
>> is that we can get away with just an integer for future needs. If 
>> integer doesn't suit, then new ioctl would need to be created. I think 
>> there's same problem if I pick some struct today (the struct may not 
>> suit tomorrow and we need to create new ioctl for the new struct).
>
> I'd like someone to back me up (or tell me I'm wrong), but...
>
> I think you can still pass a void in/out pointer, which can
> be interpreted in an IOCTL-specific way, as long as it can
> be unambiguously processed.
>
> So if you passed a non-null pointer, what it referred to
> could contain a key that defines the way to interpret it.
>
> You can't take away a behavior you've once supported, but I
> *think* you can add a new behavior (with a new structure
> that identifies itself).
>
> So if that is correct, you can extend a single IOCTL.  But
> sadly I can't tell you I'm sure this is correct.

In general you are correct that the behavior of an ioctl
command can be changed by reusing a combination of inputs that
was previously prohibited. I can't think of a case where that
would be a good idea though, as this just adds more complexity
than defining a new ioctl command code.

Interface versions and multiplexed ioctl commands are
all discouraged for the same reason.

      Arnd