Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 27 Oct 2020 16:46:58 +0100
From:   Joerg Roedel <jroedel@suse.de>
To:     "Kirill A. Shutemov" <kirill@shutemov.name>
Cc:     Arvind Sankar <nivedita@alum.mit.edu>, x86@kernel.org,
        linux-kernel@vger.kernel.org,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Kees Cook <keescook@chromium.org>
Subject: Re: RFC x86/boot/64: BOOT_PGT_SIZE definition for compressed kernel
Message-ID: <20201027154658.GG22179@suse.de>
References: <20201025004158.GA767345@rani.riverdale.lan>
 <20201027124007.xkkseswwgerlzlsl@box>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20201027124007.xkkseswwgerlzlsl@box>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

On Tue, Oct 27, 2020 at 03:40:07PM +0300, Kirill A. Shutemov wrote:
> BTW, what happens if we underestimate BOOT_PGT_SIZE? Do we overwrite
> something?

The boot code will print an error and stop the machine when allocating a
page-table page fails.

I also think that bumping BOOT_PGT_SIZE up to have more pages available
is a good short-term solution. Recycling pages will also need to take
page encryption attributes into account, as for SEV-ES the GHCB page
needs to be mapped unencrypted.

Another option to safe some memory is to make use of GB pages in the
decompression code. Machines where the current BOOT_PGT_SIZE is too
small will likely support GB pages too.

Regards,

	Joerg