SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Reserving memory using efi_mem_reserve() calls into the x86
efi_arch_mem_reserve() function. This function will insert a new EFI
memory descriptor into the EFI memory map representing the area of
memory to be reserved and marking it as EFI runtime memory. As part
of adding this new entry, a new EFI memory map is allocated and mapped.
The mapping is where a problem can occur. This new memory map is mapped
using early_memremap() and generally mapped encrypted, unless the new
memory for the mapping happens to come from an area of memory that is
marked as EFI_BOOT_SERVICES_DATA memory. In this case, the new memory will
be mapped unencrypted. However, during replacement of the old memory map,
efi_mem_type() is disabled, so the new memory map will now be long-term
mapped encrypted (in efi.memmap), resulting in the map containing invalid
data and causing the kernel boot to crash.
Since it is known that the area will be mapped encrypted going forward,
explicitly map the new memory map as encrypted using early_memremap_prot().
Cc: <stable@vger.kernel.org> # 4.14.x
Fixes: 8f716c9b5feb ("x86/mm: Add support to access boot related data in the clear")
Link: https://lore.kernel.org/all/ebf1eb29...dacky@amd.com/
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
[ardb: incorporate Kconfig fix by Arnd]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Is this in anyway related to the problem Mr. Volkerding discovered?
Ditto, plus VirtualBox-6.1.30-148432.
After 7 release candidates and 8 stable releases the 6-8 second blank screen after the BIOS check is still with us. Ditto with 5.16-rc1 through 4.
Other than that, everything I do on the computer works as it should.
Maybe I should switch to VirtualBox, Kernel 5.17.x and KVM is a crap performance....even VMware does not work properly.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,139
Original Poster
Rep:
Year 2021, Round 83
Another batch of updates has been scheduled for release on Friday, 17 December 2021, at approximately 17:00, GMT. If no problems are found while testing the release candidates, they might be available sometime on Thursday (depending on your time zone).
There is only one entry in the change log, so I'm guessing this is a "quick fix" of great importance?
Quote:
Linux 5.15.9
From: Greg Kroah-Hartman
Date: Thu Dec 16 2021 - 09:39:20 EST
I'm announcing the release of the 5.15.9 kernel.
Only change here is a permission setting of a netfilter selftest file.
No need to upgrade if this problem is not bothering you.
The updated 5.15.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.15.y
and can be browsed at the normal kernel.org git web browser: https://git.kernel.org/?p=linux/kern....git;a=summary
thanks,
greg k-h
------------
Last edited by cwizardone; 12-16-2021 at 09:14 AM.
Reason: Typo.
Being the glutton for punishment that I am I built 5.15.9 and it is running nicely with Nvidia-470.94. Also took the opportunity to include the two wishes from bassmadrigal
Wonder if there will be a 5.15.10 soon with the 42 patches
Yeah, I just built .9 thinking it had the 42 patches after seeing them listed for the 9-rc1. I guess they'll be rolled in with the next batch that come from this Sunday's mainline batch.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
