[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/vPIC: check values loaded from state save record
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Date: Wed, 25 Oct 2023 14:53:03 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wnbtn8USSL7+GRlqiH2XcA4xrz0jqmq+/ZvYey1vv6c=; b=czbATwH7ELqDWrtKTOaB1HuE2f8tdR3WqlFpLYYTxi/EvkqeG8WqV42nI/Pp6NfV9ulqjMxo0Oot4cWb6VINdxjzyRZY5oq4ahYZ4pAZfdChfgNL9mIGkoBY6Czl6wsRSiPDVj+6lGzRUcKuUUNfebcD/U68m4cZIfdvzxXXNSz8Vn1DLacKgYdjZDySPOwmNUHN9VMK6Qvf5DaCsTPLIva5n2pm5IS7NecNa6OFzCzKTsgDeKSaEslhtYhBRjCUWVptjRtSpnw4m46/oKZAjsdvD1TqyjTqx+p/zYyH4yjb46ibvT+6XEh/Bx2Ton6PWmNPRa30OhEcgRytvpxt3g==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eAXOeIRC24LgV0fNK7/iA/8lclM8ZpbujWCNLY0L08zXWv90JOLo6keDtxY4vvIlESoo3dWL1qCPKbZJPdILJvyGqVTyEeO3VvuQeincxW/zvbpwATOjl+C0l+gQ84qKGulAgoHjoggleQh7MK46bASdmsIegrqILqWO/l6V4g1gSpaoqS/Nf8Ad+1Deq47dfrLcxZsauHAnRDc+elihmYvuoZOl5vM7ba1qGXiTYquLX2LMH5M8jddrKJkw74Po0Rfc91B/359awxLJGJHUWovHB/EHkspTORB0QyZcTn4fCedfXPeuvNyuyP1Z3+Z/5ssTgwJTugcQRjcCbC5hIg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Wed, 25 Oct 2023 12:53:17 +0000
- Ironport-data: A9a23:4i2QxahoJM7EgoUyiL6BxAXcX161RxEKZh0ujC45NGQN5FlHY01je htvW2iAMqmPYTemeo8iOtmyoEIP7ZCDz4BiGgdqpCwwQygb9cadCdqndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wbuOhTraCYmYoHVMMpB4J0XpLg/Q+jpNjne+3CgaMv cKai8DEMRqu1iUc3lg8sspvkzsx+qyp0N8klgZmP6sS5AWDzyB94K83fsldEVOpGuG4IcbiL wrz5OnR1n/U+R4rFuSknt7TGqHdauePVeQmoiM+t5mK2nCulARrukoIHKN0hXNsoyeIh7hMJ OBl7vRcf+uL0prkw4zxWzEAe8130DYvFLXveRBTuuTLp6HKnueFL1yDwyjaMKVBktubD12i+ tQfLTFTaCzfjNunnrTgRqpNiP8zcszkadZ3VnFIlVk1DN4AaLWaGeDv2oUd2z09wMdTAfzZe swVLyJ1awjNaAFOPVFRD48imOCvhT/0dDgwRFC9/PJrpTSMilIvluS0WDbWUoXiqcF9hEGXq 3iA523kKhobKMae2XyO9XfEaurnxHmlBNxDTOLpnhJsqAeS6zIKJBY3bEWErcKwtnO5d4gBe lNBr0LCqoB3riRHVOLVXRe1vXqFtR40QMdLHqsx7wTl4rrZ5UOVC3YJShZFacc6r4kmSDoyz FiLktj1Qzt1v9W9Vna15rqS6zSoNkAowXQqYCYFSU4A/IPlqYRq1BbXFI4/Seiyk8H/Hiz2z 3aSti8iir4PjMkNkaKm4VTAhDHqrZ/MJuIo2jjqsquexlsRTOaYi0aAszA3Md4owF6lc2S8
- Ironport-hdrordr: A9a23:dqb6V6G4/tGZbu+VpLqEzseALOsnbusQ8zAXPhZKOGZom+ij5r mTdZMgpHnJYVcqKRYdcLW7UpVoLkmslqKdjbNwAV7AZniDhILLFvAB0WK4+UyZJ8SWzIc0vp uIGJIObeEYY2Iase/KpCGlDtA6zMCD4MmT9JzjJrRWIT2CqZsM0+60MGmm+4RNKjV7OQ==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Oct 25, 2023 at 01:51:05PM +0200, Jan Beulich wrote:
> On 25.10.2023 12:12, Roger Pau Monné wrote:
> > On Thu, May 11, 2023 at 01:50:33PM +0200, Jan Beulich wrote:
> >> Loading is_master from the state save record can lead to out-of-bounds
> >> accesses via at least the two container_of() uses by vpic_domain() and
> >> __vpic_lock(). Calculate the field from the supplied instance number
> >> instead. Adjust the public header comment accordingly.
> >>
> >> For ELCR follow what vpic_intercept_elcr_io()'s write path and
> >> vpic_reset() do.
> >>
> >> Convert ->int_output (which for whatever reason isn't a 1-bit bitfield)
> >> to boolean, also taking ->init_state into account.
> >>
> >> While there also correct vpic_domain() itself, to use its parameter in
> >> both places.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> ---
> >> Of course an alternative would be to simply reject state save records
> >> with bogus values.
> >
> > Likewise on the vPIC one, I feel it might be better to just reject
> > such bogus entries, instead of attempting to amend them.
>
> Perhaps we should discuss which route to take on the next x86 meeting?
> Then also Andrew would have a chance to voice concerns; not sure if
> he's following the thread.
I don't have a strong opinion. It seems more prone to errors to try
to adjust state that we know it's wrong. The adjustments could have
bad interactions, or we might miss other fields that also need
adjusting. Plus any such 'bogus' state is a sign of something going
wrong.
Thanks, Roger.
|
