Re: GSoC 2025 / Igor Svilenkov Bozic (Introduction)

--000000000000718c370631451a36
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Martin,

Following up on the stretch goal you suggested. I've been exploring how
this could be achieved and looking into relevant parts of the source and
boot flow.

So far, I've traced the full call path from the userland utility down to
the firmware-level SetVariable() runtime service. I've been plumbing around
how EFI variables are constructed in userspace (via set_bootorder(),
set_variable(), etc.), passed to the kernel via ioctl (EFIIOC_VAR_SET),
handled by efi_ioctl_var_set(), and ultimately relayed to the firmware via
efi_rt.rt_setvar through efi_runtime_setvar().

It looks something like this:

Userland (efi(8) utility)
=E2=94=94=E2=94=80=E2=94=80 set_bootorder(int fd, const char *target, const=
 char *bootorder)
    =E2=94=94=E2=94=80=E2=94=80 set_variable(fd, &efi_var_ioc)
        =E2=94=94=E2=94=80=E2=94=80 ioctl(fd, EFIIOC_VAR_SET, &efi_var_ioc)
            =E2=86=93 Kernel entry point
            =E2=94=94=E2=94=80=E2=94=80 efi_ioctl(dev_t dev, u_long cmd, vo=
id *data, ...)
                =E2=94=94=E2=94=80=E2=94=80 case EFIIOC_VAR_SET:
                    =E2=94=94=E2=94=80=E2=94=80 efi_ioctl_var_set(struct ef=
i_var_ioc *var)
                        =E2=94=94=E2=94=80=E2=94=80 efi_ops->efi_setvar(nam=
ebuf, &vendor, attrib,
size, data)
                            =E2=86=93 Calling Firmware's Runtime services (=
or stub)
                            =E2=94=94=E2=94=80=E2=94=80 SetVariable()
                                (writes to NVRAM eg. Boot####, BootOrder,
etc.)

I believe I've got the gist of how NetBSD boot entries are created and
where hooks could be added in sysinst to preserve and manipulate EFI
Boot#### entries.

*Example Use Case:* *User wants to install NetBSD alongside another OS
(like Linux)*
- Enumerate existing Boot#### entries
- sysinst detects existing ESP and does not wipe it
- Insert a new entry for NetBSD (e.g. 'NetBSD 10.0')
- Leaves existing Linux entries untouched.
- Update BootOrder in a safe and optional way

What needs to be done to get there (top-level guess):
- Extension of sysinst logic for bootloader placement
- Logic to detect and parse existing EFI entries
- Reuse or extend the efi(8) utility functions for variable management
- Sanity checks for BootOrder consistency
- Safe mount/handling of existing ESPs during install
- Possibly some new command-line flags or install options

I hope this should be enough to start drafting the full detailed GSoC
proposal and submit an application, since the application window is now
open as of Monday.

Thanks again,
Igor Svilenkov Bozic

On Mon, 24 Mar 2025 at 07:54, Igor Svilenkov <[email protected]> wrote:

> Hi Martin,
>
> Thanks for the feedback. That sounds good for scope expansion, kind of
> like an automated rEFInd-like functionality. I'll explore in which ways
> this may be achieved, then get back to you
>
> Best,
> Igor Svilenkov Bozic
>
> On Mon, 24 Mar 2025 at 07:04, Martin Husemann <[email protected]> wrote:
>
>> On Sun, Mar 23, 2025 at 06:22:16PM +0100, Igor Svilenkov wrote:
>> > The goal is to implement proper boot entries, making it nicer to see
>> boot
>> > menu entries such as ?NetBSD 10.0? instead of the generic
>> > ?UEFI OS?.
>>
>> Hi Igor, your proposal sounds good so far.
>>
>> How about adding a close related but different additional goal as a
>> possible
>> stretch goal (in case you get everything done quick enough)?
>>
>> The proper setup of (U)EFI boot options will make it possible to
>> enhance sysinst to allow automatic installation of NetBSD side by side
>> on the same disk with other already installed OSes, relying on the
>> (U)EFI boot selector to pick a system to boot. Strictly speaking this
>> is not part of the original project, but it is a simple extensions and
>> will be easy once you are comfortable with the sysinst internals
>> required for the boot option setup.
>>
>> Martin
>>
>

--000000000000718c370631451a36
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Martin,<br><br>Following up on the stretch goal you sug=
gested. I&#39;ve been exploring how this could be achieved and looking into=
 relevant parts of the source and boot flow.<br><br>So far, I&#39;ve traced=
 the full call path from the userland utility down to the firmware-level Se=
tVariable() runtime service. I&#39;ve been plumbing around how EFI variable=
s are constructed in userspace (via set_bootorder(), set_variable(), etc.),=
 passed to the kernel via ioctl (EFIIOC_VAR_SET), handled by efi_ioctl_var_=
set(), and ultimately relayed to the firmware via efi_rt.rt_setvar through =
efi_runtime_setvar().<br><br>It looks something like this:<br><br><span sty=
le=3D"font-family:monospace">Userland (efi(8) utility) <br>=E2=94=94=E2=94=
=80=E2=94=80 set_bootorder(int fd, const char *target, const char *bootorde=
r) =C2=A0<br>=C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 set_variable(fd, &am=
p;efi_var_ioc)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 i=
octl(fd, EFIIOC_VAR_SET, &amp;efi_var_ioc)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =E2=86=93 Kernel entry point<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 efi_ioctl(dev_t dev, u_long cmd, =
void *data, ...)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =E2=94=94=E2=94=80=E2=94=80 case EFIIOC_VAR_SET:<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=
=80 efi_ioctl_var_set(struct efi_var_ioc *var)<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=
=80=E2=94=80 efi_ops-&gt;efi_setvar(namebuf, &amp;vendor, attrib, size, dat=
a)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=86=93 Calling Firmware&#39;s Runtime servi=
ces (or stub)<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=94=94=E2=94=80=E2=94=80 SetVa=
riable()<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (writes to NVRAM eg. Boot#=
###, BootOrder, etc.)</span><br><br>I believe I&#39;ve got the gist of how =
NetBSD boot entries are created and where hooks could be added in sysinst t=
o preserve and manipulate EFI Boot#### entries.<br><br><b>Example Use Case:=
</b> <i>User wants to install NetBSD alongside another OS (like Linux)</i><=
br>- Enumerate existing Boot#### entries<br>- sysinst detects existing ESP =
and does not wipe it<br>- Insert a new entry for NetBSD (e.g. &#39;NetBSD 1=
0.0&#39;)<br>- Leaves existing Linux entries untouched.<br>- Update BootOrd=
er in a safe and optional way<br><br>What needs to be done to get there (to=
p-level guess):<br>- Extension of sysinst logic for bootloader placement<br=
>- Logic to detect and parse existing EFI entries<br>- Reuse or extend the =
efi(8) utility functions for variable management<br>- Sanity checks for Boo=
tOrder consistency<br>- Safe mount/handling of existing ESPs during install=
<br>- Possibly some new command-line flags or install options<br><br>I hope=
 this should be enough to start drafting the full detailed GSoC proposal an=
d submit an application, since the application window is now open as of Mon=
day.<br><br>Thanks again, =C2=A0<br>Igor Svilenkov Bozic</div><br><div clas=
s=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_att=
r">On Mon, 24 Mar 2025 at 07:54, Igor Svilenkov &lt;<a href=3D"mailto:svile=
[email protected]">[email protected]</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hi Marti=
n,<br><br></div>Thanks for the feedback. That=20
sounds good for scope expansion, kind of like an automated rEFInd-like=20
functionality. I&#39;ll explore in which ways this may be achieved, then ge=
t
 back to you<br><br></div>Best,<br></div>Igor Svilenkov Bozic</div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 24 Mar=
 2025 at 07:04, Martin Husemann &lt;<a href=3D"mailto:[email protected]" t=
arget=3D"_blank">[email protected]</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">On Sun, Mar 23, 2025 at 06:22:16PM +0100=
, Igor Svilenkov wrote:<br>
&gt; The goal is to implement proper boot entries, making it nicer to see b=
oot<br>
&gt; menu entries such as ?NetBSD 10.0? instead of the generic<br>
&gt; ?UEFI OS?.<br>
<br>
Hi Igor, your proposal sounds good so far.<br>
<br>
How about adding a close related but different additional goal as a possibl=
e<br>
stretch goal (in case you get everything done quick enough)?<br>
<br>
The proper setup of (U)EFI boot options will make it possible to<br>
enhance sysinst to allow automatic installation of NetBSD side by side<br>
on the same disk with other already installed OSes, relying on the<br>
(U)EFI boot selector to pick a system to boot. Strictly speaking this<br>
is not part of the original project, but it is a simple extensions and<br>
will be easy once you are comfortable with the sysinst internals<br>
required for the boot option setup.<br>
<br>
Martin<br>
</blockquote></div>
</blockquote></div>

--000000000000718c370631451a36--