From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Marczykowski Subject: Re: {xen, dom0}_vga_console_info.u.vesa_lfb.lfb_base field too small Date: Mon, 6 May 2019 12:29:53 +0200 Message-ID: <20190506102953.GW1728@mail-itl> References: <20190505132740.GT1728@mail-itl> <5CD004F2020000780022C1B2@prv1-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4689830543301568507==" Return-path: Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hNasn-0004Sa-Lv for xen-devel@lists.xenproject.org; Mon, 06 May 2019 10:30:05 +0000 In-Reply-To: <5CD004F2020000780022C1B2@prv1-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" To: Jan Beulich Cc: Juergen Gross , xen-devel List-Id: xen-devel@lists.xenproject.org --===============4689830543301568507== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vKcNkqnJHUUp475E" Content-Disposition: inline --vKcNkqnJHUUp475E Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Xen-devel] {xen, dom0}_vga_console_info.u.vesa_lfb.lfb_base field too small On Mon, May 06, 2019 at 03:57:06AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 10:04, wrote: > > On 05/05/2019 15:27, Marek Marczykowski-G=C3=B3recki wrote: > >> Hi, > >>=20 > >> I have a machine that allocate vesa LFB above 4GB, as reported by UEFI > >> GOP. At 0x4000000000 to be specific. > >> vga_console_info.u.vesa_lfb.lfb_base is a 32bit field, so it gets > >> truncated, leading to all kind of memory corruptions when something > >> writes there. > >> If that would be only about Xen, that wouldn't be that bad, but > >> unfortunately exactly the same structure is used as an interface for > >> dom0 start info (at least PV one). > >> My only idea is to introduce yet another entry in *_vga_console_info.u > >> union (efi_lfb64?) with a 64bit lfb_base field. And mark it in > >> video_type (XEN_VGATYPE_EFI_LFB64?). But I'm not sure how non-patched > >> Linux (or other supported OSes) would respond to this. xen_init_vga() = in > >> Linux doesn't seem to bail on unknown video_type, so it may be fragile. > >>=20 > >> Any better ideas? > >=20 > > In Linux kernel the screen_info structure has ext_lfb_base for that > > purpose (it contains the upper 32 bits of lfb_base). > >=20 > > We could add a similar member to Xen's dom0_vga_console_info.u.vesa_lfb > > and let the kernel detect its presence by using the value of > > start_info.console.dom0.info_size - this wouldn't require a new video > > type and old kernels would run as today. The same scheme is used for > > gbl_caps and mode_attrs already. >=20 > +1 Makes sense. That said, in Linux, VIDEO_CAPABILITY_64BIT_BASE is 2, same as COMPAT bit Xen use in gbl_caps - which is later copied to screen_info->capabilities by Linux... Another interaction is that, all extra fields (gbl_caps, mode_attrs) are skipped with XEN_VGATYPE_EFI_LFB. It will look a little confusing that bit 2 means totally different things depending on video type. And to be honest, I'm not sure if Linux wouldn't interpret COMPAT bit wrong here. BTW another problem I have on this machine is the framebuffer size. It's 3840 x 2160, which is larger than max resolution hardcoded in drivers/video/lfb.c (1920 x 1200). efi_find_gop_mode() chooses the largest one, ignoring this limit. On one hand, it should take the limit into account, but on another, increasing the limit looks quite harmless (other than the console is quite slow) and not changing the mode during boot looks better. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --vKcNkqnJHUUp475E Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlzQDKAACgkQ24/THMrX 1yzOsAf/ZsX/HyxEegb24/zWWTOdpUwHK2wPPq3YeIhYZvL3mYgXAUEdHRduXGAo 7EFnNgQORazhUjUU8e+7CXkvYT6clCF8TluvtSbQpUbyvsPT4WofBpZ8Us/DCuEQ DAPt1d8OTQ/RZ1Hl/Bz9CrFVVxqtwlSEuw3oO1bLfajXjtU8+gGNJ0k3tizCuCYE +KdFe78dLPoD8jm1LvkP8d5oe12205c8G76VdTMMGJ8qwKopqBsOOm0y5tT9GkLP qWfVIEkS2LyO+4zehd6bpZUgbm+uXrCgw6Sj8Y6hztOh/KraPXQ9Zotzgcr12QX5 AI8DK6vhAwEdgzlvwu+iWTvVYdhDVw== =vfBj -----END PGP SIGNATURE----- --vKcNkqnJHUUp475E-- --===============4689830543301568507== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============4689830543301568507==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86C9FC04A6B for ; Mon, 6 May 2019 10:30:22 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 586DE20830 for ; Mon, 6 May 2019 10:30:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="G06uzFuT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 586DE20830 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=invisiblethingslab.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hNaso-0004TL-PF; Mon, 06 May 2019 10:30:06 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hNasn-0004Sa-Lv for xen-devel@lists.xenproject.org; Mon, 06 May 2019 10:30:05 +0000 X-Inumbo-ID: e59ae5b4-6fe9-11e9-a65d-af3396406c14 Received: from wout1-smtp.messagingengine.com (unknown [64.147.123.24]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e59ae5b4-6fe9-11e9-a65d-af3396406c14; Mon, 06 May 2019 10:29:58 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 5E78B408; Mon, 6 May 2019 06:29:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 06 May 2019 06:29:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=kDjjQo 4aTFXsnnR5YAlBKIzTyFexrG7R8B28ktfuHUk=; b=G06uzFuT9+EnglW2jIIHZB LDE7d8aHdt0GEWeFyRy1qwhaeY6WF3TjsorFK4OqLnyz6ccl3W9QXJyg3fbjYmoP LheAooAbCnduZdEiS2/BuQ82GFxBMWRaGYn87ApqOHTOVwnJoXSl6s8p8SDDNqN9 ywThJI9FaaPgZENCc/+nxZt7xnHL97geQV9FEdfNV71wvdGQ45mJzZ1cv2pCcZCu p2HNdYqN42edXrgb5wnUqrfnoGsjfNq1wNFLVzZ6sgBhRk7NhHltk+OaO4DIpR8W S8BoQqO58dbS66eKaEUWeYHXOmTJmDQajKbQW0h4ZMT0dqq2LWKlChZHITDqkPVA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrjeejgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujggfsehgtderredtreejnecuhfhrohhmpeforghrvghk ucforghrtgiihihkohifshhkihcuoehmrghrmhgrrhgvkhesihhnvhhishhisghlvghthh hinhhgshhlrggsrdgtohhmqeenucffohhmrghinhepughomhdtrdhinhhfohenucfkphep ledurdeihedrfeegrdeffeenucfrrghrrghmpehmrghilhhfrhhomhepmhgrrhhmrghrvg hksehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomhenucevlhhushhtvghrufhi iigvpedt X-ME-Proxy: Received: from mail-itl (ip5b412221.dynamic.kabel-deutschland.de [91.65.34.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 27959E448F; Mon, 6 May 2019 06:29:56 -0400 (EDT) Date: Mon, 6 May 2019 12:29:53 +0200 From: Marek Marczykowski To: Jan Beulich Message-ID: <20190506102953.GW1728@mail-itl> References: <20190505132740.GT1728@mail-itl> <5CD004F2020000780022C1B2@prv1-mh.provo.novell.com> MIME-Version: 1.0 In-Reply-To: <5CD004F2020000780022C1B2@prv1-mh.provo.novell.com> User-Agent: Mutt/1.11.1+94 (9b965fac) (2019-01-05) Subject: Re: [Xen-devel] {xen, dom0}_vga_console_info.u.vesa_lfb.lfb_base field too small X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , xen-devel Content-Type: multipart/mixed; boundary="===============4689830543301568507==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Message-ID: <20190506102953.LGFYx_-rQiQwlqYoNtU9sN1zN2T08ZZN-gR2jzLwMas@z> --===============4689830543301568507== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vKcNkqnJHUUp475E" Content-Disposition: inline --vKcNkqnJHUUp475E Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Xen-devel] {xen, dom0}_vga_console_info.u.vesa_lfb.lfb_base field too small On Mon, May 06, 2019 at 03:57:06AM -0600, Jan Beulich wrote: > >>> On 06.05.19 at 10:04, wrote: > > On 05/05/2019 15:27, Marek Marczykowski-G=C3=B3recki wrote: > >> Hi, > >>=20 > >> I have a machine that allocate vesa LFB above 4GB, as reported by UEFI > >> GOP. At 0x4000000000 to be specific. > >> vga_console_info.u.vesa_lfb.lfb_base is a 32bit field, so it gets > >> truncated, leading to all kind of memory corruptions when something > >> writes there. > >> If that would be only about Xen, that wouldn't be that bad, but > >> unfortunately exactly the same structure is used as an interface for > >> dom0 start info (at least PV one). > >> My only idea is to introduce yet another entry in *_vga_console_info.u > >> union (efi_lfb64?) with a 64bit lfb_base field. And mark it in > >> video_type (XEN_VGATYPE_EFI_LFB64?). But I'm not sure how non-patched > >> Linux (or other supported OSes) would respond to this. xen_init_vga() = in > >> Linux doesn't seem to bail on unknown video_type, so it may be fragile. > >>=20 > >> Any better ideas? > >=20 > > In Linux kernel the screen_info structure has ext_lfb_base for that > > purpose (it contains the upper 32 bits of lfb_base). > >=20 > > We could add a similar member to Xen's dom0_vga_console_info.u.vesa_lfb > > and let the kernel detect its presence by using the value of > > start_info.console.dom0.info_size - this wouldn't require a new video > > type and old kernels would run as today. The same scheme is used for > > gbl_caps and mode_attrs already. >=20 > +1 Makes sense. That said, in Linux, VIDEO_CAPABILITY_64BIT_BASE is 2, same as COMPAT bit Xen use in gbl_caps - which is later copied to screen_info->capabilities by Linux... Another interaction is that, all extra fields (gbl_caps, mode_attrs) are skipped with XEN_VGATYPE_EFI_LFB. It will look a little confusing that bit 2 means totally different things depending on video type. And to be honest, I'm not sure if Linux wouldn't interpret COMPAT bit wrong here. BTW another problem I have on this machine is the framebuffer size. It's 3840 x 2160, which is larger than max resolution hardcoded in drivers/video/lfb.c (1920 x 1200). efi_find_gop_mode() chooses the largest one, ignoring this limit. On one hand, it should take the limit into account, but on another, increasing the limit looks quite harmless (other than the console is quite slow) and not changing the mode during boot looks better. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? --vKcNkqnJHUUp475E Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlzQDKAACgkQ24/THMrX 1yzOsAf/ZsX/HyxEegb24/zWWTOdpUwHK2wPPq3YeIhYZvL3mYgXAUEdHRduXGAo 7EFnNgQORazhUjUU8e+7CXkvYT6clCF8TluvtSbQpUbyvsPT4WofBpZ8Us/DCuEQ DAPt1d8OTQ/RZ1Hl/Bz9CrFVVxqtwlSEuw3oO1bLfajXjtU8+gGNJ0k3tizCuCYE +KdFe78dLPoD8jm1LvkP8d5oe12205c8G76VdTMMGJ8qwKopqBsOOm0y5tT9GkLP qWfVIEkS2LyO+4zehd6bpZUgbm+uXrCgw6Sj8Y6hztOh/KraPXQ9Zotzgcr12QX5 AI8DK6vhAwEdgzlvwu+iWTvVYdhDVw== =vfBj -----END PGP SIGNATURE----- --vKcNkqnJHUUp475E-- --===============4689830543301568507== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============4689830543301568507==--