On 01/04/2021 15:13, George Dunlap wrote:
>
>> On Apr 1, 2021, at 3:00 PM, Andrew Cooper <[email protected]> wrote:
>>
>> On 01/04/2021 14:38, George Dunlap wrote:
>>> ...grouped by submitters / maintainers
>>>
>>> Signed-off-by: George Dunlap <[email protected]>
>>> ---
>>> CC: Juergen Gross <[email protected]>
>>> CC: Jan Beulich <[email protected]>
>>> CC: Ian Jackson <[email protected]>
>>> ---
>>> CHANGELOG.md | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/CHANGELOG.md b/CHANGELOG.md
>>> index 2f26cd5c87..9c272a0113 100644
>>> --- a/CHANGELOG.md
>>> +++ b/CHANGELOG.md
>>> @@ -28,8 +28,11 @@ The format is based on [Keep a
>>> Changelog](https://keepachangelog.com/en/1.0.0/)
>>> - Factored out HVM-specific shadow code, improving code clarity and
>>> reducing the size of PV-only hypervisor builds
>>> - Added XEN_SCRIPT_DIR configuration option to specify location for Xen
>>> scripts, rather than hard-coding /etc/xen/scripts
>>> - xennet: Documented a way for the backend (or toolstack) to specify MTU
>>> to the frontend
>>> + - Fix permissions for watches on @introduceDomain and @releaseDomain: By
>>> default, only privileged domains can set watches; but specific domains can
>>> be given permission in order to allow disaggregation.
>> This is XSA-115, and isn't something new in 4.15 vs 4.14. (I think?)
> XSA-115 went public during the 4.15 development window.
>
> So on the one hand, it’s certainly effort that happened during the window,
> which it would be good to highlight. On the other hand, it was backported
> to all security supported trees (?), so it’s not something you need to update
> to 4.15 to get.
>
> Honestly not sure the best thing to suggest here.
We either want all XSAs discussed, or none of them. Possibly as simple
as "the following XSAs {...} where developed and released" ?
I recall Lars making this part of the release notes in the past.
>
>>> + - xenstore can now be live-updated on a running system.
>> This needs to be very clear that it is tech preview. It does not
>> currently work cleanly if a malicious VM deliberately holds a
>> transaction open.
> OK, I’ll add (tech preview) at the end.
SGTM.
~Andrew
