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::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 BB8C6211963F0 for ; Sun, 9 Dec 2018 23:22:40 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id h65so16472889ith.3 for ; Sun, 09 Dec 2018 23:22:40 -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=inJ5Mpj+fhu5RMieCaovqA3Jn+CXugbzP682zvF3pwQ=; b=MbBlknLuawB23Ej/RlQUlqRIsmebUA8ab5ifhIJ21H9TFFcpIr3kb4xT3aEkyZct4M sTzYjsjoRE3YIxYpC6HUqSO1u+d3hfyM5flRc7o1r4Yqdw3kZQupLte9fSjUZ7bAgA43 Lefpx2CSxW0IA5SjlV6CPKo3LOKOgKsQZA1j0= 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=inJ5Mpj+fhu5RMieCaovqA3Jn+CXugbzP682zvF3pwQ=; b=VEcjmSHypH32JjOr2fx63DwglYOWTzJo7cb4icVl9Iz6FBLpK//5Uo84KqFPSNrz61 gDabOqEgLC4PKiZY7JDRcUP7DquzXwzJSn1N90iWkAL1+tdctC00L0RKZEYN+UQ0pGFu YIgUhv7Aon9cec3tjYixf0PClqaz3Y0YOPToA2CzwTgpWFgKjlq5IJD1SYXiaRnkBHzM AM4eyOItam0iQLvqFISxf6mriBBmhyyxC+Hc1rEGQGSzitH+HlL9xZBeN81T1TJuX19X PpcEM7OmZH59eXQzZEHd+KYIyKMMTXAoFToqU6AzminB94fZkRMAm2W3g80CXdWfdZJh xIxA== X-Gm-Message-State: AA+aEWZ8zK54i4FNr94IWnIILdGgEPNvOUxULkRziKJedKDtuwFOVb0O BvRy0qReTL+liaIjNqDCCQdCBI3ImaEpNxDjv7gn7g== X-Google-Smtp-Source: AFSGD/VusCP6EBQd8HCxLXwFy2PnyvPYIr0vy6ule1GKq5JLf/GZ3DVDvoqtHUieySHEp2aBNoFgiqea0b6ISNUMcpo= X-Received: by 2002:a24:710:: with SMTP id f16mr8996862itf.121.1544426559856; Sun, 09 Dec 2018 23:22:39 -0800 (PST) MIME-Version: 1.0 References: <20181207112304.19765-1-ard.biesheuvel@linaro.org> <20181207112304.19765-4-ard.biesheuvel@linaro.org> In-Reply-To: From: Ard Biesheuvel Date: Mon, 10 Dec 2018 08:22:31 +0100 Message-ID: To: Jian J Wang Cc: "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Gao, Liming" , "Wu, Hao A" , Leif Lindholm , Laszlo Ersek , Auger Eric , Andrew Jones , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= 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 07:22:41 -0000 Content-Type: text/plain; charset="UTF-8" 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.