Re: [Xen-devel] Radical proposal: ship not-fully-tidied shim as 4.10.1

[Juergen Gross <jgross@xxxxxxxx>]

On 09/01/18 23:11, Hans van Kranenburg wrote:
> On 01/09/2018 07:22 PM, Rich Persaud wrote:
>>>> On Jan 9, 2018, at 12:56, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
>>>> wrote:
>>>>
>>>> On Tue, 9 Jan 2018, Doug Goldstein wrote:
>>>> On 1/9/18 11:33 AM, Jan Beulich wrote:
>>>>>>>> On 09.01.18 at 18:23, <anthony@xxxxxxxxxxxxx> wrote:
>>>>>> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini
>>>>>> <sstabellini@xxxxxxxxxx> wrote:
>>>>>>>>> On Tue, 9 Jan 2018, George Dunlap wrote:
>>>>>>>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <persaur@xxxxxxxxx> 
>>>>>>>>> wrote:
>>>>>>>>> On a similarly pragmatic note: would a variation of Anthony's vixen 
>>>>>>>>> patch
>>>>>> series be suitable for pre-PVH Xen 4.6 - 4.9?  These versions are 
>>>>>> currently 
>>>>>> documented as security-supported (Oct 2018 - July 2020).
>>>>>>>>
>>>>>>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a
>>>>>>>> non-polished series to 4.10, rather than exctly what the content of
>>>>>>>> that series would be.
>>>>>>>>
>>>>>>>> In the IRL conversation that preceeded this mail, the new short-term
>>>>>>>> target we discussed was:
>>>>>>>> 1. A 4.10-based shim that could boot either under HVM or PVH
>>>>>>>> 2. A script that would take an existing PV config, and spit out a) a
>>>>>>>> bootable ISO with the shim & whatever was needed, and b) a new config
>>>>>>>> that would boot the same VM, but in HVM mode with the shim
>>>>>>>>
>>>>>>>> The script + a 4.10 shim binary *should* allow most PV guests to boot
>>>>>>>> without any changes whatsoever for most older versions of Xen.
>>>>>>>>
>>>>>>>> There are a number of people for whom this won't work; I think we also
>>>>>>>> need to provide a way to transparently change PV guests into PVshim
>>>>>>>> guests.  But that will necessarily involve significant toolstack
>>>>>>>> functionality, at which point you might as well backport PVH as well.
>>>>>>>
>>>>>>> Yes, there will be a number of people that won't be covered by this fix,
>>>>>>> including those that can't use HVM/PVH mode because VT-x isn't available
>>>>>>> at all in their environment. That is the only reason to run PV today.
>>>>>>> Providing a way to transparently change PV guests into PVshim guests
>>>>>>> won't cover any of these cases. A more complete workaround to SP3 is
>>>>>>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690.
>>>>>>>
>>>>>>> That said, I realize that we are only trying to do the best we can in a
>>>>>>> very difficult situation, with very little time in our hands. I agree
>>>>>>> with Ian that we should commit something unpolished and only partially
>>>>>>> reviewed soon, even though it doesn't cover a good chunk of the userbase
>>>>>>> for one reason or another. Even if migration doesn't work, it will still
>>>>>>> help all that don't require it. It is only a partial fix by nature
>>>>>>> anyway.
>>>>>>
>>>>>> Can people be a bit more explicit about what they think should be done 
>>>>>> here?
>>>>>>
>>>>>> I'm happy to redirect effort to PVH shim if that's what the solution
>>>>>> is going to be.
>>>>>>
>>>>>> I obviously prefer the HVM approach as it works on a broad range of Xen 
>>>>>> versions
>>>>>> without modification but I'm keen to get something done quickly and
>>>>>> don't want to
>>>>>> waste effort.
>>>>>
>>>>> From what I've read today, I have no reason to believe the PVH
>>>>> shim won't work in HVM mode. How would the HVM-only approach
>>>>> be better in that case?
>>>>>
>>>>> Jan
>>>>
>>>> I feel like I should state the obvious here. Its tested over a large
>>>> data set.
>>>
>>> Right: if we are going to commit something unpolished and unreviewed,
>>> let it be at least very well tested by the submitter. Honest question:
>>> how much more dev&test we need on PVShim before we get it to similar
>>> levels of confidence?
>>
> 
>> Since the primary audience for security fixes are production
>> deployments of Xen where customer assets are at risk, is there an
>> estimate for the percentage/size of Xen deployments where PVH (not
>> only Xen 4.10) has already been deployed for production customers?
>> That could give other customers more confidence in deploying PVH in
>> production.
> +1
> 
> I have been hearing mostly-very-positive stories around, except for the
> missing pvgrub2 support. :)

https://lists.xen.org/archives/html/xen-devel/2017-11/msg01795.html

Juergen

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