Hi Sergey, On Friday, 2 October 2026 at 15:15, Sergey Bugaev <[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. > I see, thanks for clarifying and explaining the reasoning. > > 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. > It makes sense to me, with these in mind, I think the port should aim to support the PIC image eventually. I will take a look at the matter. If it turns out to be a trivial fix indeed, I have no objections to re-enable PIC support right away. If it turns out to be a fairly involved change, then I will hold off on that a bit because it is not my first priority at the moment. I am just speculating though, I can't know for certain what it'll require before I sit down and do the actual work. Also, I must mention that we compile with mcmodel=medany, and pretty much every dereference is made PC-relative, save for pointers stored in statically initialized file-scope/global variables. We still assume a kernel placed at KERNEL_MAP_BASE though, our paging implementation makes use of that assumption currently. This raises another question, who is going to patch GOT entries if we enable -fPIC? How does your port do this -- do you patch dynamic relocations during early kernel init? > > 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 > Thanks for the kind words, Hakan
