We shouldn't include unsupported code by default, with not even a means
for its building to be disabled. Convert the dependency from merely
affecting the prompt's visibility to a real one.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
We could of course go further and make the default also account for
DEBUG, as is done elsewhere.
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -193,14 +193,15 @@ config HVM_FEP
If unsure, say N.
config TBOOT
- bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED
- default y if !PV_SHIM_EXCLUSIVE
+ bool "Xen tboot support (UNSUPPORTED)"
+ depends on UNSUPPORTED
+ default !PV_SHIM_EXCLUSIVE
select CRYPTO
---help---
Allows support for Trusted Boot using the Intel(R) Trusted Execution
Technology (TXT)
- If unsure, say Y.
+ If unsure, stay with the default.
choice
prompt "Alignment of Xen image"On 3/3/22 04:49, Jan Beulich wrote: > We shouldn't include unsupported code by default, with not even a means > for its building to be disabled. Convert the dependency from merely > affecting the prompt's visibility to a real one. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > We could of course go further and make the default also account for > DEBUG, as is done elsewhere. As in you would like to adjust the default based on whether DEBUG is on or not? I guess my question is what motivation is there to adjust this selection if DEBUG is enabled or disabled? > --- a/xen/arch/x86/Kconfig > +++ b/xen/arch/x86/Kconfig > @@ -193,14 +193,15 @@ config HVM_FEP > If unsure, say N. > > config TBOOT > - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED > - default y if !PV_SHIM_EXCLUSIVE > + bool "Xen tboot support (UNSUPPORTED)" > + depends on UNSUPPORTED > + default !PV_SHIM_EXCLUSIVE > select CRYPTO > ---help--- > Allows support for Trusted Boot using the Intel(R) Trusted Execution > Technology (TXT) > > - If unsure, say Y. > + If unsure, stay with the default. > > choice > prompt "Alignment of Xen image" > Outside of the debug question, I think the proposed change is good. Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.cm>
Jan, FYI, I just noticed that Lukasz old intel email was used for this patch. I assume your tree just hasn't picked up the patch with his new email address. Copying him now so he can see your patch. v/r, dps On 3/3/22 06:50, Daniel P. Smith wrote: > On 3/3/22 04:49, Jan Beulich wrote: >> We shouldn't include unsupported code by default, with not even a means >> for its building to be disabled. Convert the dependency from merely >> affecting the prompt's visibility to a real one. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> We could of course go further and make the default also account for >> DEBUG, as is done elsewhere. > > As in you would like to adjust the default based on whether DEBUG is on > or not? I guess my question is what motivation is there to adjust this > selection if DEBUG is enabled or disabled? > >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -193,14 +193,15 @@ config HVM_FEP >> If unsure, say N. >> config TBOOT >> - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED >> - default y if !PV_SHIM_EXCLUSIVE >> + bool "Xen tboot support (UNSUPPORTED)" >> + depends on UNSUPPORTED >> + default !PV_SHIM_EXCLUSIVE >> select CRYPTO >> ---help--- >> Allows support for Trusted Boot using the Intel(R) Trusted >> Execution >> Technology (TXT) >> - If unsure, say Y. >> + If unsure, stay with the default. >> choice >> prompt "Alignment of Xen image" >> > > Outside of the debug question, I think the proposed change is good. > > Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.cm>
On 03.03.2022 12:50, Daniel P. Smith wrote: > On 3/3/22 04:49, Jan Beulich wrote: >> We shouldn't include unsupported code by default, with not even a means >> for its building to be disabled. Convert the dependency from merely >> affecting the prompt's visibility to a real one. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> --- >> We could of course go further and make the default also account for >> DEBUG, as is done elsewhere. > > As in you would like to adjust the default based on whether DEBUG is on > or not? I guess my question is what motivation is there to adjust this > selection if DEBUG is enabled or disabled? This is to have functionality enabled unless overridden in debug builds. >> --- a/xen/arch/x86/Kconfig >> +++ b/xen/arch/x86/Kconfig >> @@ -193,14 +193,15 @@ config HVM_FEP >> If unsure, say N. >> >> config TBOOT >> - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED >> - default y if !PV_SHIM_EXCLUSIVE >> + bool "Xen tboot support (UNSUPPORTED)" >> + depends on UNSUPPORTED >> + default !PV_SHIM_EXCLUSIVE >> select CRYPTO >> ---help--- >> Allows support for Trusted Boot using the Intel(R) Trusted Execution >> Technology (TXT) >> >> - If unsure, say Y. >> + If unsure, stay with the default. >> >> choice >> prompt "Alignment of Xen image" >> > > Outside of the debug question, I think the proposed change is good. > > Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.cm> Thanks. I guess there's an 'o' missing though in the email address? Jan
On 3/3/22 07:03, Jan Beulich wrote: > On 03.03.2022 12:50, Daniel P. Smith wrote: >> On 3/3/22 04:49, Jan Beulich wrote: >>> We shouldn't include unsupported code by default, with not even a means >>> for its building to be disabled. Convert the dependency from merely >>> affecting the prompt's visibility to a real one. >>> >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>> --- >>> We could of course go further and make the default also account for >>> DEBUG, as is done elsewhere. >> >> As in you would like to adjust the default based on whether DEBUG is on >> or not? I guess my question is what motivation is there to adjust this >> selection if DEBUG is enabled or disabled? > > This is to have functionality enabled unless overridden in debug builds. Maybe I am misunderstanding you. If I am wanting to debug either TXT or a configuration with TXT on and I adjust my config to turn on debug, then I would have to go turn TXT back on. Is that correct? If that is the correct understanding, honestly that concerns me because if that is being done for other config options, it would create the situation where turning on debug to track down an issue would result in a different configuration than the one I was experiencing the issue. >>> --- a/xen/arch/x86/Kconfig >>> +++ b/xen/arch/x86/Kconfig >>> @@ -193,14 +193,15 @@ config HVM_FEP >>> If unsure, say N. >>> >>> config TBOOT >>> - bool "Xen tboot support (UNSUPPORTED)" if UNSUPPORTED >>> - default y if !PV_SHIM_EXCLUSIVE >>> + bool "Xen tboot support (UNSUPPORTED)" >>> + depends on UNSUPPORTED >>> + default !PV_SHIM_EXCLUSIVE >>> select CRYPTO >>> ---help--- >>> Allows support for Trusted Boot using the Intel(R) Trusted Execution >>> Technology (TXT) >>> >>> - If unsure, say Y. >>> + If unsure, stay with the default. >>> >>> choice >>> prompt "Alignment of Xen image" >>> >> >> Outside of the debug question, I think the proposed change is good. >> >> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.cm> > > Thanks. I guess there's an 'o' missing though in the email address? Apologies for that, correct I missed the 'o' as I was typing it out. v/r, dps
On 03.03.2022 13:16, Daniel P. Smith wrote: > > On 3/3/22 07:03, Jan Beulich wrote: >> On 03.03.2022 12:50, Daniel P. Smith wrote: >>> On 3/3/22 04:49, Jan Beulich wrote: >>>> We shouldn't include unsupported code by default, with not even a means >>>> for its building to be disabled. Convert the dependency from merely >>>> affecting the prompt's visibility to a real one. >>>> >>>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>>> --- >>>> We could of course go further and make the default also account for >>>> DEBUG, as is done elsewhere. >>> >>> As in you would like to adjust the default based on whether DEBUG is on >>> or not? I guess my question is what motivation is there to adjust this >>> selection if DEBUG is enabled or disabled? >> >> This is to have functionality enabled unless overridden in debug builds. > > Maybe I am misunderstanding you. If I am wanting to debug either TXT or > a configuration with TXT on and I adjust my config to turn on debug, > then I would have to go turn TXT back on. Is that correct? If that is > the correct understanding, honestly that concerns me because if that is > being done for other config options, it would create the situation where > turning on debug to track down an issue would result in a different > configuration than the one I was experiencing the issue. In the scenario that you describe (aiui), the default setting wouldn't make a difference: If you alter an existing .config by turning on DEBUG, the .config's existing TBOOT setting wouldn't change. Defaults matter only for items which have no values recorded yet. Plus - I'm suggesting to turn the option _on_ by default when DEBUG=y, not off. Jan
On 3/3/22 07:24, Jan Beulich wrote: > On 03.03.2022 13:16, Daniel P. Smith wrote: >> >> On 3/3/22 07:03, Jan Beulich wrote: >>> On 03.03.2022 12:50, Daniel P. Smith wrote: >>>> On 3/3/22 04:49, Jan Beulich wrote: >>>>> We shouldn't include unsupported code by default, with not even a means >>>>> for its building to be disabled. Convert the dependency from merely >>>>> affecting the prompt's visibility to a real one. >>>>> >>>>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >>>>> --- >>>>> We could of course go further and make the default also account for >>>>> DEBUG, as is done elsewhere. >>>> >>>> As in you would like to adjust the default based on whether DEBUG is on >>>> or not? I guess my question is what motivation is there to adjust this >>>> selection if DEBUG is enabled or disabled? >>> >>> This is to have functionality enabled unless overridden in debug builds. >> >> Maybe I am misunderstanding you. If I am wanting to debug either TXT or >> a configuration with TXT on and I adjust my config to turn on debug, >> then I would have to go turn TXT back on. Is that correct? If that is >> the correct understanding, honestly that concerns me because if that is >> being done for other config options, it would create the situation where >> turning on debug to track down an issue would result in a different >> configuration than the one I was experiencing the issue. > > In the scenario that you describe (aiui), the default setting wouldn't > make a difference: If you alter an existing .config by turning on DEBUG, > the .config's existing TBOOT setting wouldn't change. Defaults matter > only for items which have no values recorded yet. Plus - I'm suggesting > to turn the option _on_ by default when DEBUG=y, not off. Okay, I am following now. Apologies for taking so long. I think that would be fine as TXT/tboot should be benign if enabled but tboot is not used to start Xen. v/r, dps
© 2016 - 2024 Red Hat, Inc.