On Fri, Oct 2, 2026 at 3:05 PM Hakan Candar <[email protected]> wrote: > To make things clear, we will be supporting PIC on userland once > we get the kernel to reach userland. This change applies to the > kernel image itself only.
Yes, I'm talking about the kernel image too. > Is it essential to have kernels be built with PIC to ensure best > security practices nowadays? I would be glad if you directed me > to relevant sources. It is -- for all the same reasons that it is essential in userland, it makes it harder for attackers to cause damage if they already have some memory read/write primitive. You can search for KASR (e.g. in Linux and XNU) online. > Sure, that sounds plausible. But the running assumption so far has > been a non-PIC kernel image. If we are going to commit to support > PIC as an official, blessed way to build the riscv kernel image, > then I need to take some time to verify everything works as intended > and spend time fixing existing assumptions. Well, there is practically no downside for writing PIC code on "modern" ISAs -- it's certainly more awkward on i386, but you're essentially paying nothing on either AArch64 or RISC-V. So I'd use "everything is PIC-ready" as a working assumption, and just use PIC-compatible patterns everywhere. And once you do that, there's not much of a reason not to actually enable PIC. > Please see the repository at: > > https://github.com/hakanrw/gnumach-riscv64 > > The master branch has an early physical address kernel image that > reaches the GNU Mach banner. It was tested on QEMU and my personal > test board Milk-V Mars. See the announcement: > > https://lists.gnu.org/archive/html/bug-hurd/2026-09/msg00036.html Yes, I saw the announcement -- exciting, and great work! Thanks for the repo link, I will take a look. Sergey
