[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] efifb: ignore frame buffer with invalid configuration
- To: Roger Pau Monne <roger.pau@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 21 Nov 2022 09:15:52 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=/zVZrDcTECDCUU9XSL7IpNafkjQIy37KSqkWvtAnlC4=; b=GOZ+mDebiS/642wYxuuhv6mp4fqLaDyB/VoI/v2oH4VjObrGBtIBhTf4CWwnZdRaq304HJfruLhUzj92asUaAern84mPh5UffcT8F6qkzumHBV62KrAggqJdDzKtt7iC8SGvui3m5oZHSqDKVhs0/QHAeGqVcdlTSMagNUVSbXMIccqcSpsGttniKwLySrRJQ/Og0HQ863CRgUsk4bxiEHeKnXn6dOoWO3GVRcg3CXg9EvjYvvXKLPP1TA55Z0nQDse9k9wFwugdAANpH3dOxqybXEp+TyZB3Zv5fRhHcnP/WqXN9y656xSL4La2Fo3EeaGx0wuF3MBkwm+rzkzF/Q==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ePHgTCw/0S0He11zh/wkhojr1U4TDHNyQKmx2PoL8GYkFNlGAxHIV88joeCv3GYnOaNGZK+OCNUb+5lvyGHbAPsdJUA2dvgPQCYSpUBjhcg22cu7YrEwNNpgxui+d2pJCXV0GUbsDjfRtemBetPXT8h1poCI9Tb0xcQVFG0lbu3l1s9hHYCFgZd0oVMTfbn7ej6DhiZjjFxQvcWUdAxfxZ/MSCCd4gAgRJsov5EtLIHvj1pCbC2SGs31CqiS5MLDZjAcCSjyxebyjsLo8y6kZQsH70hOGVMl8gZ7ImqtbEBSHDs6wCew9stLt+p42ByjZIWtvkfn667p11n4n5Vf5w==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Mon, 21 Nov 2022 08:16:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 18.11.2022 15:11, Roger Pau Monne wrote:
> On one of my boxes when the HDMI cable is not plugged in the
> FrameBufferBase of the EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE structure is
> set to 0 by the firmware (while some of the other fields looking
> plausible).
>
> Such (bogus address) ends up mapped in vesa_init(), and since it
> overlaps with a RAM region the whole system goes down pretty badly,
> see:
>
> (XEN) vesafb: framebuffer at 0x0000000000000000, mapped to
> 0xffff82c000201000, using 35209k, total 35209k
> (XEN) vesafb: mode is 0x37557x32, linelength=960, font 8x16
> (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:0:8:16
> (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) (XEN) �ERROR: Class:0; Subclass:0;
> Operation: 0
> ERROR: No ConOut
> ERROR: No ConIn
>
> Do like Linux and prevent using the EFI Frame Buffer if the base
> address is 0. This is inline with the logic in Linuxes
> fb_base_is_valid() function at drivers/video/fbdev/efifb.c v6.0.9.
>
> See also Linux commit 133bb070e94ab41d750c6f2160c8843e46f11b78 for
> further reference.
>
> Also prevent using Frame Buffers that have a 0 height or width, as
> those are also invalid.
>
> Signed-off-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
|
