[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] x86/livepatch: Fix livepatch application when CET is active
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Tue, 18 Apr 2023 09:28:20 +0100
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=MUhhF4R2A7KldBjtaBfEHpx11Crn0DQE8HGcoGlBhvg=; b=C+fvDBUMAGGRi7UoBxxJma9pqUy7eCMzMKALQ+HKB3oTXzzyYxzVTUspCg/SO5Wd44/3+dMMLnWdO12EFJimsLuTf2gazBm8MjdiZ3zePth+7dLtF554XlX3ARVHHnHQtCeJPYQVaO1rR+WK5q78tyyw8ZnbzotLjELlyliS+BPc2i4RIDAvf5rNY31rCC7dK4/t5YNolnq6l0RZ8cUzRB1ITSbWrTWleLx/n0fBYey3Vtkb6clGL5LYS+XAJ7WK7lq+sdOEubxcQ58E59/vP6sSzxq/zX1B3hArNipzxmPkssyWy8Qu7o8Zl9ZtplpD7z3aW1dottsPGRIvwgVe5A==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NFo7BXOrmM3Sd8nwgG9MMVmeu6plSCcUEvfghnDFfg6/uYVF3W8tYTUks2Gmilfm7li4LPMtO+6XtdC5VS3aFNoroi9FDqECFdbqLPAsjdlzTezHJPk3s/OOcKiaMz2bLjqBUjoXxojNIG34U4cRtlpEvEEGVB9ki3LviV9bZjgk/4hSosi0DrmVFBA0csxBrNP3MzK1YYMg8xZM+OjHOwSkLRedZCf4qBA+B4zPgJ+4Lvog4sD6CRmLCB1RwnPCRRbYaJRR+283fulIcDJAeRL930OKVJj5UfoNoXDeeODts5Ik+iqZXRCqaij40fL4LebSQ8Xl+IzLbe4dCuRmIA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Tue, 18 Apr 2023 08:28:50 +0000
- Ironport-data: A9a23:32uqnq1crtK8WhuYZvbD5elwkn2cJEfYwER7XKvMYLTBsI5bpzEOy mZLD2qCPfqIZWOhLox0Pojj8h4O7MSAztFhQQU/pC1hF35El5HIVI+TRqvS04F+DeWYFR46s J9OAjXkBJppJpMJjk71atANlVEliefTAOK6ULWeUsxIbVcMYD87jh5+kPIOjIdtgNyoayuAo tq3qMDEULOf82cc3lk8tuTS+XuDgNyo4GlD5gBnNagS1LPjvyJ94Kw3dPnZw0TQGuG4LsbiL 87fwbew+H/u/htFIrtJRZ6iLyXm6paLVeS/oiI+t5qK23CulQRrukoPD9IOaF8/ttm8t4sZJ OOhF3CHYVxB0qXkwIzxWvTDes10FfUuFLTveRBTvSEPpqFvnrSFL/hGVSkL0YMkFulfEz53q voaNz02MxGEm96PkfWwRbUvv5F2RCXrFNt3VnBI6xj8VapjbbWdBqLA6JlfwSs6gd1IEbDGf c0FZDFzbRPGJRpSJlMQD5F4l+Ct7pX9W2QA9BTJ+uxouC6PnWSd05C0WDbRUvWMSd9YgQCzo WXe8n6iKhobKMae2XyO9XfEaurnxHumCNhJTuLonhJsqB7P+0FPMkVKb1ymqvOEgRHna89kO 0NBr0LCqoB3riRHVOLVXRe1vXqFtR40QMdLHqsx7wTl4rXQyxaUAC4DVDEpQN8hstU/SXo11 1uKt9TzDDdrvfueTnf13qeZq3a+NDYYKUcGZDQYVk0V7t/7uoYxgxnTCNF5H8aIYsbdHDjxx 3WGqXY4jrBL0coTjf3nrBbAni6moYXPQkgt/ALLU2m57wR/Iom4e4iv7lud5vFFRGqEcmS8U LE/s5D2xIgz4VulzkRhnM1l8GmV2su4
- Ironport-hdrordr: A9a23:ejwkbaCWdMXWV/TlHem955DYdb4zR+YMi2TDtnoddfUxSKfzqy nApoV56faKskdyZJhNo7690cq7LU80l6QU3WB5B97LYOCMggSVxe9ZjLcKygeQfhHDyg==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 18/04/2023 6:58 am, Jan Beulich wrote:
> On 17.04.2023 21:34, Andrew Cooper wrote:
>> On 17/04/2023 3:51 pm, Jan Beulich wrote:
>>> On 17.04.2023 16:41, Andrew Cooper wrote:
>>>> On 17/04/2023 2:59 pm, Jan Beulich wrote:
>>>>> On 17.04.2023 15:52, Andrew Cooper wrote:
>>>>>> @@ -5879,6 +5880,73 @@ int destroy_xen_mappings(unsigned long s,
>>>>>> unsigned long e)
>>>>>> return modify_xen_mappings(s, e, _PAGE_NONE);
>>>>>> }
>>>>>>
>>>>>> +/*
>>>>>> + * Similar to modify_xen_mappings(), but used by the alternatives and
>>>>>> + * livepatch in weird contexts. All synchronization, TLB flushing, etc
>>>>>> is the
>>>>>> + * responsibility of the caller, and *MUST* not be introduced here.
>>>>>> + *
>>>>>> + * Must be limited to XEN_VIRT_{START,END}, i.e. over l2_xenmap[].
>>>>>> + * Must be called with present flags, and over present mappings.
>>>>>> + * Must be called on leaf page boundaries.
>>>>> This last sentence, while wording-wise correct, could do with making more
>>>>> explicit that it is the caller's responsibility to know whether large page
>>>>> mappings are in use, due to ...
>>>> The meaning here is really "this doesn't shatter superpages", and this
>>>> was the most concise I could come up with.
>>>>
>>>> Would ", i.e. won't shatter 2M pages." as a clarification work?
>>> Yes, that would definitely help. Nevertheless I was more after something
>>> like "..., i.e. for 2M mappings on 2M boundaries." Which, thinking about
>>> it, points out that while you have a respective check for the start
>>> address, the full 2M page would be changed even if the end address wasn't
>>> 2M aligned (but fell in the middle of a 2M page).
>> There's no nice way to check for because a range that starts on a 4k
>> non-2M boundary can legitimately end on a 2M boundary at 4k granularity.
> How about
>
> if ( l2e_get_flags(l2e) & _PAGE_PSE )
> {
> ASSERT(l1_table_offset(v) == 0);
> ASSERT(e - v >= (1UL << L2_PAGETABLE_SHIFT));
Ah, not as bad as I feared. I'll include this, and post a v3 for
completeness.
~Andrew
|
