Help with writing custom boot-loader configuration

Help with writing custom boot-loader configuration

[Raghav Gururajan]

Hello Guix!

If I want to make the "grub-bootloader" to invoke ONLY "grub-mkconfig" and NOT "grub-install", how should I modify the "bootloader" part of "operating-system" section of system configuration (config.scm)? I am looking for exact Guile Scheme Code to achieve the same. 

Thank you!

Regards,
RG.

Re: Help with writing custom boot-loader configuration

[Raghav Gururajan]

On Thu, 2019-05-30 at 10:11 +0000, Raghav Gururajan wrote:
> Hello Guix!
> 
> If I want to make the "grub-bootloader" to invoke ONLY "grub-mkconfig" and NOT "grub-install", how should I modify the "bootloader" part of "operating-system" section of system configuration (config.scm)? I am looking for exact Guile Scheme Code to achieve the same. 
> 
> Thank you!
> 
> Regards,
> RG.

Hello Ludo and Rekado!

May be with your expertise in Guile Scheme, can you please help me with the
above?

Thank you!

Regards,
RG.

Re: Help with writing custom boot-loader configuration

[Timothy Sample]

Hi Raghav,

Raghav Gururajan <rvgn@disroot.org> writes:

> On Thu, 2019-05-30 at 10:11 +0000, Raghav Gururajan wrote:
>> Hello Guix!
>> 
>> If I want to make the "grub-bootloader" to invoke ONLY
>> "grub-mkconfig" and NOT "grub-install", how should I modify the
>> "bootloader" part of "operating-system" section of system
>> configuration (config.scm)? I am looking for exact Guile Scheme Code
>> to achieve the same.
>> 
>> Thank you!
>> 
>> Regards,
>> RG.
>
> Hello Ludo and Rekado!
>
> May be with your expertise in Guile Scheme, can you please help me with the
> above?

Putting together “exact Guile Scheme Code” is a lot to ask, but I can
give you the following.  You will have to adjust it appropriately if,
for example, you are not using EFI.  Note also that this is untested,
but it is certainly close.

What you want to do is create a custom bootloader that behaves just like
GRUB except for the “installer”.  In Guix, each bootloader is defined by
a “bootloader” record.  Part of that record is an “installer” field,
which tells Guix how to install the bootloader onto the system.

In addition to whatever else you use for your config file, you will need
the following modules:

    (use-modules (gnu)
                 (guix gexp))

Now you can make your custom bootloader:

    (define grub-efi-bootloader-sans-install
      (bootloader
       (inherit grub-efi-bootloader)
       (installer #~(const #t))))

Here, “(const #t)” tells Guile to create a function that always returns
“#t”, which means “true”.  The “#~” part introduces a G-expression,
which is a handy way to write code that is intended to be run from the
build environment.

Finally, this should work as part of your configuration:

    (operating-system
      ;; ...
      (bootloader (bootloader-configuration
                   ;; ...
                   (bootloader grub-efi-bootloader-sans-install))

That is, you need to change your “bootloader-configuration” to use your
new custom bootloader.

I hope that helps!


-- Tim

Re: Help with writing custom boot-loader configuration

[Raghav Gururajan]

> Putting together “exact Guile Scheme Code” is a lot to ask, but I can
> give you the following.  You will have to adjust it appropriately if,
> for example, you are not using EFI.  Note also that this is untested,
> but it is certainly close.
> 
> What you want to do is create a custom bootloader that behaves just like
> GRUB except for the “installer”.  In Guix, each bootloader is defined by
> a “bootloader” record.  Part of that record is an “installer” field,
> which tells Guix how to install the bootloader onto the system.
> 
> In addition to whatever else you use for your config file, you will need
> the following modules:
> 
>     (use-modules (gnu)
>                  (guix gexp))
> 
> Now you can make your custom bootloader:
> 
>     (define grub-efi-bootloader-sans-install
>       (bootloader
>        (inherit grub-efi-bootloader)
>        (installer #~(const #t))))
> 
> Here, “(const #t)” tells Guile to create a function that always returns
> “#t”, which means “true”.  The “#~” part introduces a G-expression,
> which is a handy way to write code that is intended to be run from the
> build environment.
> 
> Finally, this should work as part of your configuration:
> 
>     (operating-system
>       ;; ...
>       (bootloader (bootloader-configuration
>                    ;; ...
>                    (bootloader grub-efi-bootloader-sans-install))
> 
> That is, you need to change your “bootloader-configuration” to use your
> new custom bootloader.
> 
> I hope that helps!
> 

Thank you very much.

Regards,
RG.

Re: Help with writing custom boot-loader configuration

[Jack Hill]

On Mon, 3 Jun 2019, Raghav Gururajan wrote:

> On Thu, 2019-05-30 at 10:11 +0000, Raghav Gururajan wrote:
>> Hello Guix!
>>
>> If I want to make the "grub-bootloader" to invoke ONLY "grub-mkconfig" 
>> and NOT "grub-install", how should I modify the "bootloader" part of 
>> "operating-system" section of system configuration (config.scm)? I am 
>> looking for exact Guile Scheme Code to achieve the same.
>>
>> Thank you!
>>
>> Regards,
>> RG.


RG,

My first thought after reading your question was 
<https://lists.gnu.org/archive/html/help-guix/2019-05/msg00275.html>. 
However, I guess you need something else, but I'm not sure what it is. Can 
you explain more what you're trying to do? Thanks!

Best,
Jack

Re: Help with writing custom boot-loader configuration

[Raghav Gururajan]

> 
> My first thought after reading your question was 
> <https://lists.gnu.org/archive/html/help-guix/2019-05/msg00275.html>. 

Yes, I was looking for a method other than using (const ~#t).

> However, I guess you need something else, but I'm not sure what it is. Can 
> you explain more what you're trying to do? Thanks!

I was looking for a way to directly alter the behaviour of grub-installer. The
two of all functions of grub-installer are "grub-install" and "grub-mkconfig".
The former install grub binaries on disk and the latter generates grub
configuration file inside root partition under boot directory. I was thinking if
there is a straight-forward way to make the grub-installer to invoke ONLY "grub-
mkconfig" and NOT "grub-install"??

Regards,
RG.

Re: Help with writing custom boot-loader configuration

[Timothy Sample]

Hi Raghav,

Raghav Gururajan <rvgn@disroot.org> writes:

>> 
>> My first thought after reading your question was 
>> <https://lists.gnu.org/archive/html/help-guix/2019-05/msg00275.html>. 
>
> Yes, I was looking for a method other than using (const ~#t).

Heh.  I didn’t see this before.  Sorry for sending you code you already
had!

>> However, I guess you need something else, but I'm not sure what it is. Can 
>> you explain more what you're trying to do? Thanks!
>
> I was looking for a way to directly alter the behaviour of grub-installer. The
> two of all functions of grub-installer are "grub-install" and "grub-mkconfig".
> The former install grub binaries on disk and the latter generates grub
> configuration file inside root partition under boot directory. I was thinking if
> there is a straight-forward way to make the grub-installer to invoke ONLY "grub-
> mkconfig" and NOT "grub-install"??

I’m not quite sure what you are asking, since Guix does not use
“grub-mkconfig”.  It has its own way of generating a GRUB configuration
file.  The “#~(const #t)” trick is the Guix version of running
“grub-mkconfig” and not “grub-install”.  Is it working for you?

Is it that you want to use “grub-mkconfig” instead of Guix’s normal
method?  To be honest, it may be possible, but it’s only for the brave
of heart (or at least for those who can tolerate a lot of annoying
difficulties).  :)  The easiest way to do that would be to install GRUB
and run “grub-mkconfig” manually.


-- Tim

Re: Help with writing custom boot-loader configuration

[Raghav Gururajan]

> Heh.  I didn’t see this before.  Sorry for sending you code you already
> had!

That's okay. No worries.

> I’m not quite sure what you are asking, since Guix does not use
> “grub-mkconfig”.  It has its own way of generating a GRUB configuration
> file.  The “#~(const #t)” trick is the Guix version of running
> “grub-mkconfig” and not “grub-install”.  Is it working for you?

It works. Was curious about other alternatives. Btw, is it possible make guix to
 automatically GPG-Sign the "grub.cfg" it generates during "guix system init" or
"guix system reconfigure" ??

> Is it that you want to use “grub-mkconfig” instead of Guix’s normal
> method?  To be honest, it may be possible, but it’s only for the brave
> of heart (or at least for those who can tolerate a lot of annoying
> difficulties).  :)  The easiest way to do that would be to install GRUB
> and run “grub-mkconfig” manually.

Thanks for the suggestion.

Regards,
RG.

Guix and intrusion detection (was Re: Help with writing custom boot-loader configuration)

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

Hello Raghav,

Raghav Gururajan <rvgn@disroot.org> writes:

[...]

> It works. Was curious about other alternatives. Btw, is it possible make guix to
>  automatically GPG-Sign the "grub.cfg" it generates during "guix system init" or
> "guix system reconfigure" ??

I cannot (still) help patching guix this way, but from a security POV
this is interesting, providing you explain what you are trying to
achieve :-)

Anyway:

1. to sign, guix should have a secret key and that key may be easily
stolen (modulo encryption but that's another story...)

2. to verify a list of system admins signatures guix just needs public
keys and that's easy to provide, the not so easy part is patching guix I
guess

3. signature of "grub.cfg" - or other store items - should be done on
*another* machine and items deployed to the host (there is some POC and
custom code around in guix-devel for this)

Could GPG signature *verification* of selected core parts (bootloader,
initrd, kernel... guix itself) of our reproducible system make us
confident that instrusions via physical access to hardware are
automatically detected and notified by guix? [1]

...or I'm exagerating here and Guix already provides a good path to do
effective intrusion detection, even with remote hosts potentially
available to physical instrusion?

Thoughts?

[...]

Thanks! Gio'.


[1] let's call it Trusting Remote Trust problem

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]