Re: [PATCH v2 1/6] ia64: Remove support

[Ard Biesheuvel]

On Fri, 12 May 2023 at 00:41, matoro
<matoro_mailinglist_grub-devel@matoro.tk> wrote:
>
> On 2023-05-11 18:09, Ard Biesheuvel wrote:
> > On Thu, 11 May 2023 at 20:59, matoro
> > <matoro_mailinglist_grub-devel@matoro.tk> wrote:
> >>
> >> On 2023-05-11 10:29, Ard Biesheuvel wrote:
> >> > On Thu, 11 May 2023 at 15:34, John Paul Adrian Glaubitz
> >> > <glaubitz@physik.fu-berlin.de> wrote:
> >> >>
> >> >> On Thu, 2023-05-11 at 14:17 +0200, Ard Biesheuvel wrote:
> >> >> > On Thu, 11 May 2023 at 14:14, John Paul Adrian Glaubitz
> >> >> > <glaubitz@physik.fu-berlin.de> wrote:
> >> >> > >
> >> >> > > On Thu, 2023-05-11 at 14:06 +0200, Ard Biesheuvel wrote:
> >> >> > > > Itanium IA-64 support is obsolete, and implements its own flavor 
> >> >> > > > of EFI
> >> >> > > > boot that deviates from other architectures. Given that IA64 is 
> >> >> > > > unused
> >> >> > > > and unmaintained, it makes no sense to pretend that the EFI 
> >> >> > > > changes we
> >> >> > > > are making are tested or supported on IA64, so let's just get rid 
> >> >> > > > of it.
> >> >> > >
> >> >> > > But I just recently tested GRUB from git on IA64 and it worked 
> >> >> > > without
> >> >> > > any problems. We're using GRUB to boot Debian on IA64.
> >> >> > >
> >> >> >
> >> >> > IA-64 is a dead platform, and a waste of electricity.
> >> >>
> >> >> I was just making a statement regarding the testability of the code.
> >> >> That's all.
> >> >>
> >> >
> >> > Fair enough. That is good to know actually - that way, we have a known
> >> > working state right before we remove it.
> >> >
> >> >> > Feel free to keep using it, but please stop demanding that our people
> >> >> > keep wasting their time on it. If you want to support it in Debian,
> >> >> > you can carry it as a downstream patch and shoulder the maintenance
> >> >> > burden.
> >> >>
> >> >> Who is "our people"? Do you think that you are part of the community
> >> >> and
> >> >> I am not? I don't think this kind of hostility is justified. Neither
> >> >> you
> >> >> nor I own this project.
> >> >>
> >> >
> >> > Apologies - I had meant to type 'other people' not 'our people'. I
> >> > rarely contribute to GRUB myself, so I wouldn't consider myself more a
> >> > part of this community than anyone else.
> >> >
> >> > But my point remains: I have inferred from your response (and your
> >> > involvement in similar discussions around the Linux kernel) that you
> >> > would prefer Itanium support to be retained, right?
> >> >
> >> > So could you explain who you think should carry the maintenance
> >> > burden? IA64 will be the only EFI architecture in GRUB that does not
> >> > boot via an EFI stub in Linux, and this deviation means that retaining
> >> > support for it is going to take actual developer and maintainer
> >> > bandwidth. GRUB gets very little of that as it is, which means that
> >> > keeping IA64 support alive comes at the cost of worse support for
> >> > other architectures and platforms. (The series that this patch is part
> >> > of breaks the ia64 build, and i i struggle to see why i should care
> >> > about that)
> >> >
> >> > Very few of those people have access to such systems to begin with
> >> > (probably none), and the companies that manufactured them stopped
> >> > supporting them in the open source years ago, so testing these changes
> >> > is not straight-forward, making it unreasonable to demand this from
> >> > contributors. Also, it is unclear to me why the needs of the few
> >> > people that do still run such a system are not served by a build based
> >> > on today's GRUB tree, and why ia64 support needs to be retained going
> >> > forward.
> >> >
> >> > I'll leave it to the maintainers whether to merge this patch or not,
> >> > but if this needs to keep working on ia64 as well, someone else will
> >> > have to step up.
> >>
> >> Hi, I also have a functioning GRUB install on ia64 EFI.  My machine is
> >> fully open and available for debugging work, including on kernel and
> >> bootloader (hard resets can be done via management console).
> >>
> >> If there is any way this support can be saved or at least delayed by
> >> providing real hardware to work on, please reach out.  The environment
> >> is completely remote and available for anybody who would like to give
> >> it
> >> a try.
> >
> > Thanks, this could be helpful if we manage to find people that have
> > the bandwidth to keep working on this. Would you be willing to spend
> > time and development effort yourself on building and installing GRUB
> > from the upstream repository on this machine (which is a bit more
> > complicated than running kernels or user space programs)? Which distro
> > and version are you using btw?
>
> Yes, of course.  I am running Gentoo (rolling), so everything is already
> built from source anyway.  Updating to the latest git revision and
> adding drop-in patches are both part of the package manager and can be
> done in a single command.
>
> > And just out of curiosity, why does this matter to you? Given that the
> > ia64 firmware, the hardware and the linux boot protocol have not
> > changed in a decade, wouldn't it make much more sense to stick with a
> > stable, current version of GRUB, assuming that these are machines that
> > need to be kept in working order? What kind of workloads are you
> > running on these machines?
>
> I am simply an enthusiast of alternative architectures.  In particular I
> think it's the only way to keep ourselves honest about portability, and
> also the only way to ensure that many ecosystems truly build from
> source, as there's no way to pull down random binary code from the
> internet on platforms like this.
>
> I bought this hardware at great personal expense specifically for this
> purpose - testing OSS on it, and making it available to upstreams with
> an interest for developing/debugging.  I already update to and run
> official GRUB releases, as well as every kernel mainline point release
> (and have already bisected kernel regressions resulting in boot failures
> before).
>

Thanks for providing this background. It is good to know that such
support is available, but I don't think GRUB should be one of the
projects making use of it tbh.

> > For ia64, there are no upsides to running newer GRUB code with changes
> > applied to the EFI layer, as these involve protocols and other
> > functionality that the ia64 firmware simply does not implement. In the
> > best case, it works exactly the same as it does today. In the worst
> > case, it bricks your box and someone has to go down and reinstall the
> > bootloader (or more) using some kind of rescue image. Future EFI work
> > will be focused on tightening memory permissions and implementing
> > other robustness and hardening improvements, and these changes might
> > tickle bugs in older firmware in ways we cannot anticipate at this
> > point.
> >
> > So what exactly would we be trying to achieve by keeping ia64
> > supported in upstream GRUB? Is it really important enough to justify
> > asking contributors to spend time and effort on it rather than on
> > something else?
>
> Reinstalling a bootloader is definitely no problem.  The machine is
> either running builds/test suites or sitting idle.  Gentoo Releng
> produces installation CD's that I regularly test on a USB stick, so a
> live/rescue environment is trivial:
> https://gentoo.osuosl.org//releases/ia64/autobuilds/
>
> I don't have basically any say here.  I am not a GRUB developer.  I
> cannot help rewrite the code myself.  I'm not even officially
> representing a distro like Glaubitz.  If the GRUB maintainers are of the
> opinion that it is not worth the effort to maintain the support, that is
> sad but understandable.  Just thought I'd pipe up and offer what little
> I can to help, if it's desired.

Much appreciated.

But the question was why you think it is important that GRUB remains
among the set of programs running on this system that are built from
the latest source? GRUB is just a bootloader that implements the
Linux/ia64 boot protocol based on protocols exposed by the EFI
firmware, and neither side has changed in over a decade, or is going
to change in the future. Today's GRUB works as well on ia64 today as
it is ever going to run in the future.

So what is the point? Why would you risk running the latest GRUB
(carrying substantial changes in its EFI layer)? Just to prove the
point that it still works?

There is nothing wrong with that, of course. Personally, I think
Itanium is not worth anyone's time. But I fully support anyone's right
to spend it however they want.

*However*, that is not the issue I am raising here. The issue I am
raising is that the EFI layer in GRUB is likely to change
substantially if we want to stay relevant, and comply with the tighter
logo requirements that OEMs are going to implement for 'more secure'
systems. After this series is applied, IA64 is the only EFI
architecture in GRUB that boots in bare metal mode rather than via the
EFI stub in the Linux kernel.

There are a few options here:
- contributors will be requested (and required) to at least build test
their changes if they affect ia64, and to work with folks like
yourself to see if they break anything at runtime;
- the maintainer is in charge of this, perhaps with some automation
for the build tests, so that they can push back on changes that
regress ia64;
- we merge such changes without regard for ia64, and leave it to
enthusiasts like yourself to contribute fixes for ia64 once you notice
a regression;
- we decide that GRUB 2.xx (whichever was the most recent release at
the time of the decision) is good enough to boot Linux on ia64 for the
remaining life time of the architecture, and remove it from the GRUB
tree.

So the final option has my preference (in case that wasn't obvious),
and I am simply asking why having IA64 in top-of-tree GRUB is so
important to you, to the extent that you would ask other people to
spend their valuable time on it. It is clear that you made an
investment in IA64, but that by itself does not justify requiring
others to do the same (timewise or moneywise)

Thanks,
Ard.