From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Siddharth Chandrasekaran <sidcha@amazon.de>
Cc: Siddharth Chandrasekaran <sidcha.dev@gmail.com>,
Liran Alon <liran@amazon.com>,
Ioannis Aslanidis <iaslan@amazon.de>,
linux-hyperv@vger.kernel.org, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org,
Siddharth Chandrasekaran <sidcha@amazon.de>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Wei Liu <wei.liu@kernel.org>, Dexuan Cui <decui@microsoft.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH] asm-generic/hyperv: Fix struct hv_message_header ordering
Date: Thu, 29 Jul 2021 15:52:46 +0200 [thread overview]
Message-ID: <87eebh9qhd.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20210729133702.11383-1-sidcha@amazon.de>
Siddharth Chandrasekaran <sidcha@amazon.de> writes:
> According to Hyper-V TLFS Version 6.0b, struct hv_message_header members
> should be defined in the order:
>
> message_type, reserved, message_flags, payload_size
>
> but we have it defined in the order:
>
> message_type, payload_size, message_flags, reserved
>
> that is, the payload_size and reserved members swapped.
Indeed,
typedef struct
{
HV_MESSAGE_TYPE MessageType;
UINT16 Reserved;
HV_MESSAGE_FLAGS MessageFlags;
UINT8 PayloadSize;
union
{
UINT64 OriginationId;
HV_PARTITION_ID Sender;
HV_PORT_ID Port;
};
} HV_MESSAGE_HEADER;
> Due to this mix
> up, we were inadvertently causing two issues:
>
> - The payload_size field has invalid data; it didn't cause an issue
> so far because we are delivering only timer messages which has fixed
> size payloads the guest probably did a sizeof(payload) instead
> relying on the value of payload_size member.
>
> - The message_flags was always delivered as 0 to the guest;
> fortunately, according to section 13.3.1 message_flags is also
> treated as a reserved field.
>
> Although this is not causing an issue now, it might in future (we are
> adding more message types in our VSM implementation) so fix it to
> reflect the specification.
I'm wondering how this works for Linux-on-Hyper-V as
e.g. vmbus_on_msg_dpc() checks for mininum and maximum payload length:
payload_size = msg_copy.header.payload_size;
if (payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT) {
WARN_ONCE(1, "payload size is too large (%d)\n", payload_size);
goto msg_handled;
}
entry = &channel_message_table[msgtype];
if (!entry->message_handler)
goto msg_handled;
if (payload_size < entry->min_payload_len) {
WARN_ONCE(1, "message too short: msgtype=%d len=%d\n", msgtype, payload_size);
goto msg_handled;
}
Maybe it's vice versa, the header is correct and the documentation is wrong?
>
> Signed-off-by: Siddharth Chandrasekaran <sidcha@amazon.de>
> ---
> include/asm-generic/hyperv-tlfs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/asm-generic/hyperv-tlfs.h b/include/asm-generic/hyperv-tlfs.h
> index 56348a541c50..a5540e9b171f 100644
> --- a/include/asm-generic/hyperv-tlfs.h
> +++ b/include/asm-generic/hyperv-tlfs.h
> @@ -284,9 +284,9 @@ union hv_port_id {
> /* Define synthetic interrupt controller message header. */
> struct hv_message_header {
> __u32 message_type;
> - __u8 payload_size;
> - union hv_message_flags message_flags;
> __u8 reserved[2];
> + union hv_message_flags message_flags;
> + __u8 payload_size;
> union {
> __u64 sender;
> union hv_port_id port;
--
Vitaly
next prev parent reply other threads:[~2021-07-29 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 13:37 [PATCH] asm-generic/hyperv: Fix struct hv_message_header ordering Siddharth Chandrasekaran
2021-07-29 13:52 ` Vitaly Kuznetsov [this message]
2021-07-29 14:07 ` Wei Liu
2021-07-29 14:26 ` Siddharth Chandrasekaran
2021-07-29 16:56 ` Wei Liu
2021-07-30 9:35 ` Siddharth Chandrasekaran
2021-07-31 6:51 ` [asm] b5b51922df: kvm-unit-tests.hyperv_stimer.fail kernel test robot
2021-07-31 6:51 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87eebh9qhd.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=arnd@arndb.de \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=iaslan@amazon.de \
--cc=kys@microsoft.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liran@amazon.com \
--cc=sidcha.dev@gmail.com \
--cc=sidcha@amazon.de \
--cc=sthemmin@microsoft.com \
--cc=wei.liu@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.