From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6733521E9780A for ; Tue, 5 Sep 2017 16:01:06 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f199so11192863ita.1 for ; Tue, 05 Sep 2017 16:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mtzjq2U4Kktv3T8DkGx9ZPsniiDkAAv///u8FJKkxBk=; b=A+T6OEap+huLUJ0PHT8U4GABjbtbJonnvo/307KgJeXDfCdE3MlCYjakxig7FCaqOY Ek3FW0MMmSN2Wvy6s1e9Jj51kVFwdIH81FUSwx3NkeHDxwQmlgj3gZl9yeou9cFNRJt6 Fh9Xt9dV7SmMnjJOebpDWxBYji4u9fccy0FuU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Mtzjq2U4Kktv3T8DkGx9ZPsniiDkAAv///u8FJKkxBk=; b=JpXFsT3/56bSDOQmil/KeXcUB5iI2TUq/WKyVjvZHBjM5z1WStscnmDL5kGCUvLJ+Y 5ekWV2t22h23wAACSz18h4wT8ZNLJkIPqmdBVaXNkjnYdl1mGpKCc5zikSLCqygZy/wo REdD25zzBSBHkBnCszmBjD20H3oZ3o2QBcKgVuECdQJoDLFNgaZ5L7WOsf+418fKxxjt koNKorvi1N0cEBeaDY8GbCgoFF3k7uxROLj6fvZEe7s5fqOg9+Y7i2MGZSH1o2i3vkBQ Mv5GQI48wFXP3Z8RC8ao4tllMqoAj/AszwU+Nw3CWujGsZhlWF+BY+Z5ZvGITztveJqZ JBTQ== X-Gm-Message-State: AHPjjUhNhMndgPLGui7CmI3N9zhZDtXxIq13vmqAKWoQjXbQjeK/SA8p nE9vXdlqUsWIwIIwpOvwhC3QyQvHxNdu X-Google-Smtp-Source: ADKCNb5TcS/RoxxoAngq/+e7wj+VNo/h2mNNDteMs2RyOSarbWddvu97NWmtuTTIR+3LsKnq8DjqCBYvh4RkPlLVNXE= X-Received: by 10.36.184.4 with SMTP id m4mr884952ite.41.1504652635210; Tue, 05 Sep 2017 16:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.162.1 with HTTP; Tue, 5 Sep 2017 16:03:54 -0700 (PDT) In-Reply-To: <0edadd86-44aa-9c65-eb3a-be801e8ec1eb@redhat.com> References: <1504265045-19008-1-git-send-email-brijesh.singh@amd.com> <1504265045-19008-2-git-send-email-brijesh.singh@amd.com> <04fefb16-23d5-f6df-0657-9d4c5e96ac57@redhat.com> <4f286363-6f04-bee0-8b12-34b50a813e70@amd.com> <5992734a-1ded-9d4b-36bd-99c13f30ca32@redhat.com> <0edadd86-44aa-9c65-eb3a-be801e8ec1eb@redhat.com> From: Ard Biesheuvel Date: Wed, 6 Sep 2017 00:03:54 +0100 Message-ID: To: Laszlo Ersek Cc: Tom Lendacky , Jordan Justen , "edk2-devel@lists.01.org" , Jiewen Yao , Star Zeng Subject: Re: [PATCH 1/5] OvmfPkg/VirtioNetDxe: map VRING using VirtioRingMap() X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:01:06 -0000 Content-Type: text/plain; charset="UTF-8" On 5 September 2017 at 23:37, Laszlo Ersek wrote: > On 09/06/17 00:18, Ard Biesheuvel wrote: >> On 5 September 2017 at 22:59, Laszlo Ersek wrote: >>> On 09/05/17 23:11, Ard Biesheuvel wrote: > >>>> (which means it could be the second time it was called). >>> >>> Side remark: the CoreExitBootServices() implementation does not notice >>> memory map changes incurred by the ExitBootServices() handlers, in my >>> interpretation. >>> >>> CoreExitBootServices() has a MapKey (= "memmap generation") check early >>> on, in CoreTerminateMemoryMap(). This check catches memmap changes >>> between the last GetMemoryMap(), and the call to ExitBootServices(). >>> >>> After this check succeeds, the notify functions are kicked, and on this >>> path, CoreExitBootServices() simply cannot return any other value than >>> EFI_SUCCESS. So whatever mess the individual callbacks make, it doesn't >>> notice or report. >>> >> >> CoreExitBootServices() disables the timer first, and so it will return >> with event dispatch disabled if it fails, ensuring that it is no >> longer possible for an event handler to be invoked between >> GetMemoryMap and ExitBootServices. > > True, but that's not what I meant -- I meant that, if an EBS handler > violates its contract and changes the memory map (= "it makes mess"), on > the call stack of > > CoreNotifySignalList (&gEfiEventExitBootServicesGuid); > > then CoreExitBootServices() won't notice it, it won't return an error, > and the caller of EBS() won't go back to calling GetMemoryMap() again. > Ah right. So the only thing the memory map key protects against is inadvertent interruptions by event handlers that modify the memory map after GetMemoryMap(). It does not protect against programming errors.