[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH L1TF MDS GT v3 1/2] common/grant_table: harden bound accesses
- To: Norbert Manthey <nmanthey@xxxxxxxxx>
- From: Jan Beulich <JBeulich@xxxxxxxx>
- Date: Tue, 30 Jul 2019 13:23:55 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=suse.com;dmarc=pass action=none header.from=suse.com;dkim=pass header.d=suse.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-SenderADCheck; bh=rY7L2p/MzHohN+vjwziEflQGdfX4XRK/xvP/3szE39U=; b=Iy49+a4B+FWaG2i5WIeBi1AO8sL8I6F9hKF8vb0HqnuDN5N6q6Atc4G7Kqe2fJ7/5Emz8asdv0WitGy4pA8XY8ov3PVraHk5TSzZbY+6ASvIYzp4osrkzmfUPzaqQxku8gRqMvMhFDoV4DpLVIFB+ixgBbV6ttRh17OMgV1rFemza6B4KlTUcjopNxfR8/hBN3bKY0GgUKbguY0BUbuvwqz4bKW42T52+1JEoou5Lr2P99N/ghenmJ5lgGm8acymavxK7np/8Rrvt+Dqi2NseZz5sEfjFfzD/zndJPI4tQln6jB4e4hKq3zdk5xXRYoT2HdJZcTRujBuKtF0AuZekQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e+WwsEBDhZ4i+suX56lVnNk4SUtGr8EB87mc49FBjFYsWL365iTt0PENFnp+wRFN6I3rqBPss6fKCaVykx21PpQrPNFSL/VMe9a0bMcZzrWGgqQ58FKK92qjhb2AVHsCaBrQLBeIhpGi3qJAdU6ovOqKPGlIF+EHkHFJmxL7E9aZ7aNQiqSjdcNg7hoVpUw0l9lan91991+rlCdevQiNgqSYgJIfheTuYIh2NIIgzcpInAHLaxmZBOni+hi0XVHJJ/J6p5ROdI/wiL1txTKUQ/kji6h4rc15plYmDUeUvyDAko6mp9FHjUhWBsYayHsYWI5FyH3fJFQ8WI7G4s3FbA==
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=JBeulich@xxxxxxxx;
- Cc: Juergen Gross <JGross@xxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wei.liu2@xxxxxxxxxx>, KonradRzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, IanJackson <ian.jackson@xxxxxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Martin Pohlack <mpohlack@xxxxxxxxx>, PawelWieczorkiewicz <wipawel@xxxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, DavidWoodhouse <dwmw@xxxxxxxxxxxx>, Martin Mazein <amazein@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, BjoernDoebel <doebel@xxxxxxxxx>
- Delivery-date: Tue, 30 Jul 2019 13:30:38 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHVOI9EFD+2Co2LEUukceT0T/LFJ6bQUgiAgBLmMgqAAAqwgA==
- Thread-topic: [PATCH L1TF MDS GT v3 1/2] common/grant_table: harden bound accesses
On 30.07.2019 14:44, Norbert Manthey wrote:
> On 7/18/19 14:09, Jan Beulich wrote:
>> On 12.07.2019 10:51, Norbert Manthey wrote:
>>> Guests can issue grant table operations and provide guest controlled
>>> data to them. This data is used as index for memory loads after bound
>>> checks have been done. To avoid speculative out-of-bound accesses, we
>>> use the array_index_nospec macro where applicable, or the macro
>>> block_speculation. Note, the block_speculation macro is used on all
>>> path in shared_entry_header and nr_grant_entries. This way, after a
>>> call to such a function, all bound checks that happened before become
>>> architectural visible, so that no additional protection is required
>>> for corresponding array accesses. As the way we introduce an lfence
>>> instruction might allow the compiler to reload certain values from
>>> memory multiple times, we try to avoid speculatively continuing
>>> execution with stale register data by moving relevant data into
>>> function local variables.
>>>
>>> Speculative execution is not blocked in case one of the following
>>> properties is true:
>>> - path cannot be triggered by the guest
>>> - path does not return to the guest
>>> - path does not result in an out-of-bound access
>>> - path cannot be executed repeatedly
>> I notice this sentence is still there without modification. If you
>> don't want to drop it (and then perhaps make changes to a few more
>> paths), can we at least settle on a less firm statement like "path
>> is unlikely to be executed repeatedly in rapid succession"?
>
> I will drop the last condition, and post an update one more time.
FAOD - there's no strict need to post another version. If we can
settle on the wording, this is easy enough to change while committing.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
