linux-kernel - Re: [PATCH v5 13/13] tty: gunyah: Add tty console driver for RM Console Services

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: <Y0kSB9ZFoK1WJVLi@kroah.com>
Date:   Fri, 14 Oct 2022 09:38:47 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Elliot Berman <quic_eberman@...cinc.com>
Cc:     Arnd Bergmann <arnd@...db.de>, Jiri Slaby <jirislaby@...nel.org>,
        Bjorn Andersson <quic_bjorande@...cinc.com>,
        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>,
        Prakruthi Deepak Heragu <quic_pheragu@...cinc.com>,
        Andy Gross <agross@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Sudeep Holla <sudeep.holla@....com>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Corbet <corbet@....net>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 13/13] tty: gunyah: Add tty console driver for RM
 Console Services

On Thu, Oct 13, 2022 at 01:54:36PM -0700, Elliot Berman wrote:
> 
> 
> On 10/11/2022 11:55 PM, Greg Kroah-Hartman wrote:
> > On Tue, Oct 11, 2022 at 03:04:47PM -0700, Elliot Berman wrote:
> > > 
> > > 
> > > On 10/11/2022 4:09 AM, Arnd Bergmann wrote:
> > > > On Tue, Oct 11, 2022, at 8:02 AM, Jiri Slaby wrote:
> > > > > On 11. 10. 22, 2:08, Elliot Berman wrote:
> > > > > > +
> > > > > > +	/* below are for printk console.
> > > > > > +	 * gh_rm_console_* calls will sleep and console_write can be called from
> > > > > > +	 * atomic ctx. Two xmit buffers are used. The active buffer is tracked with
> > > > > > +	 * co_xmit_idx. Writes go into the co_xmit_buf[co_xmit_idx] buffer.
> > > > > > +	 * A work is scheduled to flush the bytes. The work will swap the active buffer
> > > > > > +	 * and write out the other buffer.
> > > > > > +	 */
> > > > > 
> > > > > Ugh, why? This is too ugly and unnecessary. What about passing the kfifo
> > > > > to gh_rm_console_write() instead? You do memcpy() there anyway.
> > > > 
> > > > Another problem here is that you really want the console output to be
> > > > printed from atomic context, otherwise one would never see e.g. the
> > > > output of a panic() call. Having a deferred write is probably fine for
> > > > normal tty operations, but you probably want a different device for the
> > > > console here, e.g. the hvc_dcc driver.
> > > > 
> > > 
> > > Yes, that is our perspective on the RM console driver as well. I'll make
> > > this more explicit in the Kconfig/commit text. We expect most VMs
> > > (especially Linux) to use some other console mechanism provided by their
> > > VMM. I'm submitting here because we are presently using RM console on some
> > > of our VMs where we have other ways to collects logs on panic. It also makes
> > > it easier to implement a simple virtual machine manager that does not want
> > > to virtualize a serial device or have a virtio stack.
> > 
> > The whole goal of virtio was so that we would not have all of these
> > random custom drivers for new hypervisors all over the place, requiring
> > custom userspace interaction with them.
> > 
> > Please use virtio, that's what it is there for, don't create a new
> > console device if you do not have to.
> 
> We have a lightweight VM product use case today that doesn't want to support
> an entire virtio stack just for a console. This VM already has a Gunyah
> stack present, and to facilitate their console needs, we want to give them
> the Gunyah console.
> 
> There are a few other hypervisors that also provide a console facility in
> Linux: Xen, ePAPR hypervisor and z/VM.

Those all pre-dated virtio.  Please do not reinvent the wheel, again,
this is explicitly what virtio was designed for, so that we would not
have per-device/hypervisor drivers constantly being forced to be added.

Learn from the past mistakes and just use the interfaces and apis we
already have.  You don't have to have a "heavy" VM to support just a
virtio console, and in fact, all the code is already written for you!

thanks,

greg k-h