[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230913052714.GA29112@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
Date: Tue, 12 Sep 2023 22:27:14 -0700
From: Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
To: Mathias Krause <minipli@...ecurity.net>
Cc: linux-hyperv@...r.kernel.org,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: [PATCH] x86/hyperv/vtl: Replace real_mode_header only under
Hyper-V
On Mon, Sep 11, 2023 at 10:00:59AM +0200, Mathias Krause wrote:
> On 08.09.23 17:02, Saurabh Singh Sengar wrote:
> > On Fri, Sep 08, 2023 at 12:26:10PM +0200, Mathias Krause wrote:
> >> Booting a CONFIG_HYPERV_VTL_MODE=y enabled kernel on bare metal or a
> >> non-Hyper-V hypervisor leads to serve memory corruption as
> >
> > FWIW, CONFIG_HYPERV_VTL_MODE is not expected to be enabled for non VTL
> > platforms.
>
> Fair enough, but there's really no excuse to randomly crashing the
> kernel if one forgot to RTFM like I did. The code should (and easily
> can) handle such situations, especially if it's just a matter of a two
> line change.
Thanks, I understand your concern. We don't want people to enable this
flag by mistake and see unexpected behaviours.
To add extra safety for this flag, we can make this flag dependent on
EXPERT config.
- Saurabh
Powered by blists - more mailing lists