linux-kernel - Re: [PATCH 1/1] virtio_console: fix missing byte order handling for cols and rows

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: <20250422123901.6beac282.pasic@linux.ibm.com>
Date: Tue, 22 Apr 2025 12:39:01 +0200
From: Halil Pasic <pasic@...ux.ibm.com>
To: Amit Shah <amit@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>,
        virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, "Michael S. Tsirkin"
 <mst@...hat.com>,
        stable@...r.kernel.org,
        Maximilian Immanuel Brandtner
 <maxbr@...ux.ibm.com>,
        Halil Pasic <pasic@...ux.ibm.com>
Subject: Re: [PATCH 1/1] virtio_console: fix missing byte order handling for
 cols and rows

On Wed, 16 Apr 2025 15:49:40 +0200
Amit Shah <amit@...nel.org> wrote:

> On Sat, 2025-03-22 at 01:29 +0100, Halil Pasic wrote:
> > As per virtio spec the fields cols and rows are specified as little
> > endian. Although there is no legacy interface requirement that would
> > state that cols and rows need to be handled as native endian when
> > legacy
> > interface is used, unlike for the fields of the adjacent struct
> > virtio_console_control, I decided to err on the side of caution based
> > on some non-conclusive virtio spec repo archaeology and opt for using
> > virtio16_to_cpu() much like for virtio_console_control.event.
> > Strictly
> > by the letter of the spec virtio_le_to_cpu() would have been
> > sufficient.
> > But when the legacy interface is not used, it boils down to the same.
> > 
> > And when using the legacy interface, the device formatting these as
> > little endian when the guest is big endian would surprise me more
> > than
> > it using guest native byte order (which would make it compatible with
> > the current implementation). Nevertheless somebody trying to
> > implement
> > the spec following it to the letter could end up forcing little
> > endian
> > byte order when the legacy interface is in use. So IMHO this
> > ultimately
> > needs a judgement call by the maintainers.  
> 
> The patch looks fine to me, but can you reword this message to say what
> you chose and why (and not have the bit about judgment call by
> maintainers in there)?  If it sounds right, it'll be acked and merged.
> If not, we'll work to ensure it's all good -- so the judgment calls
> happen on the list, rather than mentioning this way in the commit.
> 

Sorry for the late response! I was vacationing last week.

Would you be so kind to propose a more fortunate wording? My intention
was actually to say what did I choose (I choose virtio16_to_cpu() over
virtio_le_to_cpu()) and why (if we go strictly by the words of the spec
virtio_le_to_cpu() would be right and  virtio16_to_cpu() would be wrong,
but  assumed that we forgot to put the right words into the spec it is
the other way around; and MST confirmed that indeed those words need
to be added to the spec).

The part on the judgment call is because, for me there is no way to
tell if those words are missing from the spec because of intention or
because of omission.

Regards,
Halil