lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 17 Mar 2022 16:16:26 +0300 From: Beru Shinsetsu <windowz414@...weeb.org> To: Boris Petkov <bp@...en8.de>, Thomas Gleixner <tglx@...utronix.de> Cc: Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, GNU/Weeb Mailing List <gwml@...weeb.org>, linux-kernel@...r.kernel.org, Alviro Iskandar Setiawan <alviro.iskandar@...weeb.org> Subject: Re: [PATCH] boot install: Partially refactor the logic for detecting bootloader On Thu, 2022-03-17 at 12:36 +0000, Boris Petkov wrote: > On March 16, 2022 5:32:21 PM UTC, Beru Shinsetsu > <windowz414@...weeb.org> wrote: > > While running `make install` after building the kernel and > > installing > > modules on several distros like EndeavourOS, there would be a > > pretty > > little output (To be exact, "Cannot find LILO") due to lack of LILO > > bootloader, which is really uncommon for a user to have it while > > GRUB is there. > > As a matter of fact I saw this yesterday on one of the test boxes > here and was wondering why I am even seeing this. I guess I had pure luck having this patch seen? xd > So before we do anything, it'd be prudent to know what has changed > recently to cause this error message to happen. Because we would have > to backport a fix to some kernels probably. To be honest with you, nothing has changed _just recently_ to cause this error message to come up. It was a long living thing (since the time LILO check has appeared and the last change to it was in 2007. I can't find when did the check appear for the first time as Linus apparently ripped off the whole history from before 2.16.12-rc2.), just was unseen as most of Linux distros love to ship their own ways to install kernels... except Arch Linux and distros based on it, as they have Arch User Repository to automatically compile the kernel locally and make a PacMan package out of the artifacts using some external package manager like Yay or Aura. And if you have checked the ServerFault forum thread I have appended in original commit message, you can see it was there for really long and has been happening only on Arch Linux or distros based on it, like EndeavourOS. I have also tested this out on my environment (I have EndeavourOS on my laptop's HDD and Ubuntu Budgie on my USB HDD). I get the error message on Endeavour while I don't on Ubuntu Budgie if I run `make install` without this patch I made applied. But if I apply this patch then run it, it works on both. TL;DR, this was something that has been there since 2.x and wasn't patched ever since, so here I do as I figured out how it's handled without requirement of user interaction, through this patch. Commit ripping off the history from before 2.16.12-rc2: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (Linux-2.6.12-rc2) Last commit towards LILO check: 47f82189b185bf4b0de4ebce237850e8d3b1d0b6 (broken lilo check on make install) > Thx. And I thank you for your attention! :) -- Beru Shinsetsu
Powered by blists - more mailing lists