Re: [Xen-devel] [PATCH 0/6] arm: more kconfig configurability and small default configs

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 19 Apr 2018, Lars Kurth wrote:
> 19/04/2018, 17:32, "Julien Grall" <julien.grall@xxxxxxx> wrote:
> 
>     
>     
>     On 18/04/18 23:15, Stefano Stabellini wrote:
>     > Hi all,
>     
>     Hi,
>     
>     > This patch series is the first step toward building a small certifiable
>     > Xen hypervisor for ARM boards.
>     > 
>     > First, the series makes a few changes to allow disabling more kconfig
>     > options: most of them already exist but cannot be disabled.
>     > 
>     > Then, it introduces a reference kconfig for Renesas RCar (due to popular
>     > demand, candidate for certifications) and for QEMU aarch64 (not for
>     > certifications, but useful for debugging).
>     
>     While I could be tempt by more option to be configurable in Kconfig with 
>     some caveats (see below), I quite dislike the idea of providing a config 
>     per board. A few reasons:
>       - Where do we draw the line on config we accept for a given board?
>       - Do we have to test them every release?
>       - What if we add a new option?

I discussed this topic with Julien over a call this morning. It seems to
us that the best way forward is to follow this simple rule:

* Only accept and keep kconfig that are regularly tested for each release *

We already maintain a table of supported boards for Xen on ARM. We ask
members of the community to test Xen on these boards during the code
freeze. We mark as supported only the ones for which we get positive
responses.

In this case, if nobody steps up to test Xen with a specific kconfig
during the code freeze, the kconfig will be dropped.


>       - What does it mean in term of security support?

I replied to this question here:

https://marc.info/?l=xen-devel&m=152417791426130


>     Regarding the Kconfig, allowing more option to be selected by the user 
>     means that it will increasingly be more difficult for the community to 
>     help user in debug. More that we today don't provide a way to embed the 
>     .config in Xen binary. So if you happen to clean you repo, then you are 
>     screw to reproduce it.
>     
>     Furthermore, if we decide to impose CONFIG_XEN_EXPERT=y when using those 
>     .config, then you happen to drop one by mistake you end up rewrite you 
>     .config which is not really nice.
>     
> Maybe the easiest way to solve this is to emit the config into the serial 
> output. That should be easy enough to implement while not requiring any 
> ABI/interface changes

We have a better idea: we can embedded the kconfig into the Xen binary.
In fact, we even have a Jira ticket for it already:

https://xenproject.atlassian.net/browse/XEN-38

I'll try to come up with a patch and make it part of this series.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel