From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::141; helo=mail-it1-x141.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 02ED82119AC24 for ; Mon, 10 Dec 2018 06:53:47 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id z7so17724022iti.0 for ; Mon, 10 Dec 2018 06:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AvCHVpP3CamgfnseYZLyHn4FsdcRIUb/YwCKUm3ArMM=; b=UOJgvYy4jML22upT711eviexwbDet8U851V5drosn77HoeXS/QfjhrflL6XXPW3sTX HTdbV8cZo66dylb55eBraObcSqBzFrGZCRCJ/fObG5aZtFsoOMlekFahLcAz9mzC4A6C 8y58hhuum+ul2o4wxR8v7r57r4dUOJcr6g0Ic= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AvCHVpP3CamgfnseYZLyHn4FsdcRIUb/YwCKUm3ArMM=; b=Gf0amN16JyTCxr79Ayxq3q5Rqcnwy2lyAA4ilhRA9bCkmCY0ve18GJIchOhRCPBEWT U/OSPAbxs6kQrV6OmZ4Nl0ia+SBKayp/6o6Fdh/7hNHZVo5rcRR7XY7MCFHKD6TcfgXS 9mf+em4SnSJysjxwONz7y671Eh6ykd4L9oym/v2k0hzLMPWA3reCeIuowIqbriPlPAOw p+F0LpK/PmMtJ31KxyWMBDuAJLDck8Ru5sCZmWpjUTd1gFx5BHr74FDCbOdTxS4iK6I3 h2dENn2n2wTd5m1fjTsr8XKm3JA60tBdN7eGB06GVCy5ZPQ1kDIA3TeroEp5U8lNUViL 4KXw== X-Gm-Message-State: AA+aEWaRQ/x97wd9ljDTvywTPgksUwrlMfyrYy/ezJGc+rq+nSTsicDV +QarMXjGYjSmgwbVOE3geQ1k4NqxqaoPAyAbwicbeg== X-Google-Smtp-Source: AFSGD/VuUOSjH4tEkPUyxgsqjdJcHOv6XJCCLaQWkW0Xo70ve2dRacGPtnfU9L54iJn8IZC4+cyhJmypQy/nNERlBEU= X-Received: by 2002:a02:183:: with SMTP id 3mr11984627jak.130.1544453626973; Mon, 10 Dec 2018 06:53:46 -0800 (PST) MIME-Version: 1.0 References: <20181207112304.19765-1-ard.biesheuvel@linaro.org> <20181207112304.19765-4-ard.biesheuvel@linaro.org> <4A89E2EF3DFEDB4C8BFDE51014F606A14E3898F8@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E3898F8@SHSMSX104.ccr.corp.intel.com> From: Ard Biesheuvel Date: Mon, 10 Dec 2018 15:53:33 +0100 Message-ID: To: "Gao, Liming" Cc: Jian J Wang , Andrew Jones , "Wu, Hao A" , "edk2-devel@lists.01.org" , "Kinney, Michael D" , Laszlo Ersek Subject: Re: [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 14:53:48 -0000 Content-Type: text/plain; charset="UTF-8" On Mon, 10 Dec 2018 at 15:52, Gao, Liming wrote: > > Ard: > I prefer to define MAX_ALLOC_ADDRESS together with MAX_ADDRESS in ProcessorBind.h. I don't want to leave the choice to override MAX_ALLOC_ADDRESS definition. > Seems reasonable. What should be the value for X64? > Thanks > Liming > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel > > Sent: Monday, December 10, 2018 3:23 PM > > To: Wang, Jian J > > Cc: Andrew Jones ; Wu, Hao A ; edk2-devel@lists.01.org; Gao, Liming > > ; Kinney, Michael D ; Laszlo Ersek > > Subject: Re: [edk2] [RFC PATCH 3/7] MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account > > > > On Mon, 10 Dec 2018 at 03:04, Wang, Jian J wrote: > > > > > > Hi Ard, > > > > > > I think MAX_ALLOC_ADDRESS will affect other archs besides ARM. Please do enough > > > test for them (IA32/X64 for my concern). > > > > > > > For all other architectures, MAX_ADDRESS == MAX_ALLOC_ADDRESS is > > always true, so these changes only affect AARCH64. > > > > > In addition, do you think it's safer to replace MAX_ADDRESS with MAX_ALLOC_ADDRESS > > > in MemoryAllocationLib like following situation? > > > > > > (MdeModulePkg\Library\DxeCoreMemoryAllocationLib\MemoryAllocationLib.c) > > > VOID * > > > InternalAllocateCopyPool ( > > > IN EFI_MEMORY_TYPE PoolType, > > > IN UINTN AllocationSize, > > > IN CONST VOID *Buffer > > > ) > > > { > > > VOID *Memory; > > > > > > ASSERT (Buffer != NULL); > > > ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1)); > > > ... > > > > This assert ensures that the copied buffer does not extend across the > > end of the address space and wraps. This is a separate concern, and is > > similar to numerous other occurrences of MAX_ADDRESS that maybe we > > should update as well at some point. However, it does not affect page > > allocation at all, it only puts an upper bound on the *size* of the > > allocation. So the changes as they are will be sufficient to ensure > > that AllocateCopyPool() does not allocate from a region that is not > > addressable by the CPU. > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel