Visa Hankala <v...@hankala.org> wrote:
> On Sat, Sep 23, 2023 at 02:26:18PM +0000, Klemens Nanni wrote:
> > On Sat, Sep 23, 2023 at 01:11:32PM +0200, Mark Kettenis wrote:
> > > > Date: Thu, 21 Sep 2023 22:30:01 +0000
> > > > From: Klemens Nanni <k...@openbsd.org>
> > > >
> > > > In comparison to MI boot which only cares about /bsd.upgrade's x bit,
> > > > powerpc64 rdboot just wants a regular file.
> > > >
> > > > Require and strip u+x before execution to prevent sysupgrade(8) loop.
> > > > I'm new to powerpc64 and can't think of a reason to be different.
> > > >
> > > > Feedback? Objection? OK?
> > >
> > > So there is a problem with this approach. Calling chmod() will mean
> > > the bootloader will change the filesystem. What happens if you're
> > > booting with a root filesystem that was not cleanly unmounted?
> > > Modifying a forcibly mounted filesystem may not be without risk.
> >
> > Isn't that already the case with chmo() /etc/random.seed?
> >
> > Can you explain how that is not a problem in other non-kernel boot loaders
> > using libsa's ufs2_open() instead of mount(2)?
>
> chmod() through libsa's filesystem code modifies only the inode.
Yes, it is very minimal. I studied the code, and as far as I could see one
block is written back.
> Doing a mount-chmod-unmount cycle using the kernel triggers multiple
> writes to the filesystem.
For ffs, around 20 blocks if I studied it right. For libsa, I think 3
blocks are written back.
Majority of those are rewrites of recently read blocks.
I think the risk is overplayed, and we haven't heard of real damage have
we?
> In the past, I have pondered if octeon (and powerpc64) bootcode should
> use libsa instead of replicating the MI boot code. I did not use libsa
> initially because the libsa and libc APIs differ, and I did not want
> to use custom system call stubs. The original octboot/kexec interface
> was not suitable for libsa use, either.
Correct, I remember this discussion. It would be complicated interfacing
to the stupid libsa interface from anywhere else. It's not just libsa that
is the problem, but a new independent consumer. It will be fragile.
> However, the libsa and libc worlds can be reconciled with a trick.
> The libsa code is first compiled in standalone mode into a relinkable
> object ("saboot"). This object is then tweaked to avoid name conflicts
> with libc. Finally, the object is linked with glue code and libc into
> a proper rdboot executable that the kernel can run.
>
> Some have seen this before.
Yes. And I still worry about it. You still have a new application linked
against crappy libsa.
Next, someone changes libsa for amd64, the only architecture as far as they
are concerned, ok maybe they check arm64 also. But they don't ensure that
you get the memo. (Whoever does that change doesn't even *consider* the
chance that their code will affect another architecture, it's bad -- they
don't even mentally process that there are other architectures in the tree).
saboot continues to compile, but the rules of libsa have changed, and the
consequences are undefined.
But if you stick with ffs, those kind of yahoo operations are more rare.
So I'm not sure of the tradeoff.
