* Remotely choose a menu entry
@ 2014-11-29 1:10 Brugnara Daniele
2014-11-29 16:03 ` Andrei Borzenkov
2014-12-02 16:22 ` Autopilot, a module for remotely doing things Brugnara Daniele
0 siblings, 2 replies; 24+ messages in thread
From: Brugnara Daniele @ 2014-11-29 1:10 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi all.
I'm thinking about a system that boots with a wol packet. Who sends this
packet in 99% of cases, is far away from that computer and it could be
useful to boot into a different system instead of the default one. (please
keep in mind that changing the default option in grub is not a option for
this specific use case)
If a wol can be delivered successfully, an UDP packet containing simple
datas should be enough to achieve this.
Something like this:
- MAC: the destination device mac address
- choice: a number (can be empty)
- commandLine: a full commandline (a choice or this..)
- more? I don't know for now..
This option should be enabled in the grub.conf by the user.
What do you think about? Could this be useful? Am I missing something, like
a tool that does this automagically?
I've read about an eth-to-serial but it's not what I want.
PXE or bootp is not an option here. I don't want to manage another
server...
Thanks for your time.
Daniele.
[-- Attachment #2: Type: text/html, Size: 1262 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Remotely choose a menu entry
2014-11-29 1:10 Remotely choose a menu entry Brugnara Daniele
@ 2014-11-29 16:03 ` Andrei Borzenkov
2014-11-29 16:16 ` Brugnara Daniele
2014-12-02 16:22 ` Autopilot, a module for remotely doing things Brugnara Daniele
1 sibling, 1 reply; 24+ messages in thread
From: Andrei Borzenkov @ 2014-11-29 16:03 UTC (permalink / raw)
To: Brugnara Daniele; +Cc: grub-devel
В Sat, 29 Nov 2014 01:10:28 +0000
Brugnara Daniele <daniele@brugnara.me> пишет:
> Hi all.
>
> I'm thinking about a system that boots with a wol packet. Who sends this
> packet in 99% of cases, is far away from that computer and it could be
> useful to boot into a different system instead of the default one. (please
> keep in mind that changing the default option in grub is not a option for
> this specific use case)
>
> If a wol can be delivered successfully, an UDP packet containing simple
> datas should be enough to achieve this.
>
> Something like this:
>
> - MAC: the destination device mac address
> - choice: a number (can be empty)
> - commandLine: a full commandline (a choice or this..)
> - more? I don't know for now..
>
> This option should be enabled in the grub.conf by the user.
>
> What do you think about? Could this be useful? Am I missing something, like
> a tool that does this automagically?
>
Yes, it could probably be implemented as a command that loops listening
for magic packet and then sets default menu option. Of course, you
would need to consider security aspects (who is allowed to send
packet, how it is authenticated etc).
> I've read about an eth-to-serial but it's not what I want.
> PXE or bootp is not an option here. I don't want to manage another
> server...
>
> Thanks for your time.
>
> Daniele.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Remotely choose a menu entry
2014-11-29 16:03 ` Andrei Borzenkov
@ 2014-11-29 16:16 ` Brugnara Daniele
2014-12-01 8:19 ` Parmeshwr_Prasad
2014-12-01 23:13 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 2 replies; 24+ messages in thread
From: Brugnara Daniele @ 2014-11-29 16:16 UTC (permalink / raw)
To: Andrei Borzenkov, Brugnara Daniele; +Cc: grub-devel
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
I am thinking about a secret key known from both sender and receiver and
encode/decode the packet using this, a strong algorithm, of course.
Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com> ha
scritto:
> В Sat, 29 Nov 2014 01:10:28 +0000
> Brugnara Daniele <daniele@brugnara.me> пишет:
>
> > Hi all.
> >
> > I'm thinking about a system that boots with a wol packet. Who sends this
> > packet in 99% of cases, is far away from that computer and it could be
> > useful to boot into a different system instead of the default one.
> (please
> > keep in mind that changing the default option in grub is not a option for
> > this specific use case)
> >
> > If a wol can be delivered successfully, an UDP packet containing simple
> > datas should be enough to achieve this.
> >
> > Something like this:
> >
> > - MAC: the destination device mac address
> > - choice: a number (can be empty)
> > - commandLine: a full commandline (a choice or this..)
> > - more? I don't know for now..
> >
> > This option should be enabled in the grub.conf by the user.
> >
> > What do you think about? Could this be useful? Am I missing something,
> like
> > a tool that does this automagically?
> >
>
> Yes, it could probably be implemented as a command that loops listening
> for magic packet and then sets default menu option. Of course, you
> would need to consider security aspects (who is allowed to send
> packet, how it is authenticated etc).
>
> > I've read about an eth-to-serial but it's not what I want.
> > PXE or bootp is not an option here. I don't want to manage another
> > server...
> >
> > Thanks for your time.
> >
> > Daniele.
>
>
[-- Attachment #2: Type: text/html, Size: 2155 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Remotely choose a menu entry
2014-11-29 16:16 ` Brugnara Daniele
@ 2014-12-01 8:19 ` Parmeshwr_Prasad
2014-12-01 10:37 ` Andrei Borzenkov
2014-12-01 23:13 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 1 reply; 24+ messages in thread
From: Parmeshwr_Prasad @ 2014-12-01 8:19 UTC (permalink / raw)
To: grub-devel, arvidjaar
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]
Is your idea is to send kernel+grub+initramfs through magic packet ? if yes then lot of wol design should change first.
Regards
Parmeshwr
From: grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org [mailto:grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org] On Behalf Of Brugnara Daniele
Sent: Saturday, November 29, 2014 9:47 PM
To: Andrei Borzenkov; Brugnara Daniele
Cc: grub-devel@gnu.org
Subject: Re: Remotely choose a menu entry
I am thinking about a secret key known from both sender and receiver and encode/decode the packet using this, a strong algorithm, of course.
Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com<mailto:arvidjaar@gmail.com>> ha scritto:
В Sat, 29 Nov 2014 01:10:28 +0000
Brugnara Daniele <daniele@brugnara.me<mailto:daniele@brugnara.me>> пишет:
> Hi all.
>
> I'm thinking about a system that boots with a wol packet. Who sends this
> packet in 99% of cases, is far away from that computer and it could be
> useful to boot into a different system instead of the default one. (please
> keep in mind that changing the default option in grub is not a option for
> this specific use case)
>
> If a wol can be delivered successfully, an UDP packet containing simple
> datas should be enough to achieve this.
>
> Something like this:
>
> - MAC: the destination device mac address
> - choice: a number (can be empty)
> - commandLine: a full commandline (a choice or this..)
> - more? I don't know for now..
>
> This option should be enabled in the grub.conf by the user.
>
> What do you think about? Could this be useful? Am I missing something, like
> a tool that does this automagically?
>
Yes, it could probably be implemented as a command that loops listening
for magic packet and then sets default menu option. Of course, you
would need to consider security aspects (who is allowed to send
packet, how it is authenticated etc).
> I've read about an eth-to-serial but it's not what I want.
> PXE or bootp is not an option here. I don't want to manage another
> server...
>
> Thanks for your time.
>
> Daniele.
[-- Attachment #2: Type: text/html, Size: 5156 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Remotely choose a menu entry
2014-12-01 8:19 ` Parmeshwr_Prasad
@ 2014-12-01 10:37 ` Andrei Borzenkov
2014-12-01 10:43 ` Parmeshwr_Prasad
0 siblings, 1 reply; 24+ messages in thread
From: Andrei Borzenkov @ 2014-12-01 10:37 UTC (permalink / raw)
To: Parmeshwr_Prasad; +Cc: The development of GNU GRUB
On Mon, Dec 1, 2014 at 11:19 AM, <Parmeshwr_Prasad@dell.com> wrote:
> Is your idea is to send kernel+grub+initramfs through magic packet ?
No.
> if yes
> then lot of wol design should change first.
>
>
>
> Regards
>
> Parmeshwr
>
>
>
> From: grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org
> [mailto:grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org] On Behalf Of
> Brugnara Daniele
> Sent: Saturday, November 29, 2014 9:47 PM
> To: Andrei Borzenkov; Brugnara Daniele
> Cc: grub-devel@gnu.org
> Subject: Re: Remotely choose a menu entry
>
>
>
> I am thinking about a secret key known from both sender and receiver and
> encode/decode the packet using this, a strong algorithm, of course.
>
> Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com> ha
> scritto:
>
> В Sat, 29 Nov 2014 01:10:28 +0000
> Brugnara Daniele <daniele@brugnara.me> пишет:
>
>> Hi all.
>>
>> I'm thinking about a system that boots with a wol packet. Who sends this
>> packet in 99% of cases, is far away from that computer and it could be
>> useful to boot into a different system instead of the default one. (please
>> keep in mind that changing the default option in grub is not a option for
>> this specific use case)
>>
>> If a wol can be delivered successfully, an UDP packet containing simple
>> datas should be enough to achieve this.
>>
>> Something like this:
>>
>> - MAC: the destination device mac address
>> - choice: a number (can be empty)
>> - commandLine: a full commandline (a choice or this..)
>> - more? I don't know for now..
>>
>> This option should be enabled in the grub.conf by the user.
>>
>> What do you think about? Could this be useful? Am I missing something,
>> like
>> a tool that does this automagically?
>>
>
> Yes, it could probably be implemented as a command that loops listening
> for magic packet and then sets default menu option. Of course, you
> would need to consider security aspects (who is allowed to send
> packet, how it is authenticated etc).
>
>> I've read about an eth-to-serial but it's not what I want.
>> PXE or bootp is not an option here. I don't want to manage another
>> server...
>>
>> Thanks for your time.
>>
>> Daniele.
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Remotely choose a menu entry
2014-12-01 10:37 ` Andrei Borzenkov
@ 2014-12-01 10:43 ` Parmeshwr_Prasad
2014-12-01 11:29 ` Andrei Borzenkov
0 siblings, 1 reply; 24+ messages in thread
From: Parmeshwr_Prasad @ 2014-12-01 10:43 UTC (permalink / raw)
To: arvidjaar; +Cc: grub-devel
If you wanted system to boot with wol package then it should get kernel and initrd from somewhere.
What is your final goal? How you will get all required binaries ?
Regards
Parmeshwr
-----Original Message-----
From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
Sent: Monday, December 01, 2014 4:08 PM
To: Prasad, Parmeshwr
Cc: The development of GNU GRUB
Subject: Re: Remotely choose a menu entry
On Mon, Dec 1, 2014 at 11:19 AM, <Parmeshwr_Prasad@dell.com> wrote:
> Is your idea is to send kernel+grub+initramfs through magic packet ?
No.
>
> if yes then lot of wol design should change first.
>
>
>
> Regards
>
> Parmeshwr
>
>
>
> From: grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org
> [mailto:grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org] On
> Behalf Of Brugnara Daniele
> Sent: Saturday, November 29, 2014 9:47 PM
> To: Andrei Borzenkov; Brugnara Daniele
> Cc: grub-devel@gnu.org
> Subject: Re: Remotely choose a menu entry
>
>
>
> I am thinking about a secret key known from both sender and receiver
> and encode/decode the packet using this, a strong algorithm, of course.
>
> Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com>
> ha
> scritto:
>
> В Sat, 29 Nov 2014 01:10:28 +0000
> Brugnara Daniele <daniele@brugnara.me> пишет:
>
>> Hi all.
>>
>> I'm thinking about a system that boots with a wol packet. Who sends
>> this packet in 99% of cases, is far away from that computer and it
>> could be useful to boot into a different system instead of the
>> default one. (please keep in mind that changing the default option in
>> grub is not a option for this specific use case)
>>
>> If a wol can be delivered successfully, an UDP packet containing
>> simple datas should be enough to achieve this.
>>
>> Something like this:
>>
>> - MAC: the destination device mac address
>> - choice: a number (can be empty)
>> - commandLine: a full commandline (a choice or this..)
>> - more? I don't know for now..
>>
>> This option should be enabled in the grub.conf by the user.
>>
>> What do you think about? Could this be useful? Am I missing
>> something, like a tool that does this automagically?
>>
>
> Yes, it could probably be implemented as a command that loops listening
> for magic packet and then sets default menu option. Of course, you
> would need to consider security aspects (who is allowed to send
> packet, how it is authenticated etc).
>
>> I've read about an eth-to-serial but it's not what I want.
>> PXE or bootp is not an option here. I don't want to manage another
>> server...
>>
>> Thanks for your time.
>>
>> Daniele.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Remotely choose a menu entry
2014-12-01 10:43 ` Parmeshwr_Prasad
@ 2014-12-01 11:29 ` Andrei Borzenkov
2014-12-01 11:30 ` Parmeshwr_Prasad
0 siblings, 1 reply; 24+ messages in thread
From: Andrei Borzenkov @ 2014-12-01 11:29 UTC (permalink / raw)
To: Parmeshwr_Prasad; +Cc: The development of GNU GRUB
On Mon, Dec 1, 2014 at 1:43 PM, <Parmeshwr_Prasad@dell.com> wrote:
>
> If you wanted system to boot with wol package then it should get kernel and initrd from somewhere.
> What is your final goal? How you will get all required binaries ?
>
Are you asking me? I'm not a topic starter.
> Regards
> Parmeshwr
>
> -----Original Message-----
> From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
> Sent: Monday, December 01, 2014 4:08 PM
> To: Prasad, Parmeshwr
> Cc: The development of GNU GRUB
> Subject: Re: Remotely choose a menu entry
>
> On Mon, Dec 1, 2014 at 11:19 AM, <Parmeshwr_Prasad@dell.com> wrote:
>> Is your idea is to send kernel+grub+initramfs through magic packet ?
>
> No.
>
>>
>> if yes then lot of wol design should change first.
>>
>>
>>
>> Regards
>>
>> Parmeshwr
>>
>>
>>
>> From: grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org
>> [mailto:grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org] On
>> Behalf Of Brugnara Daniele
>> Sent: Saturday, November 29, 2014 9:47 PM
>> To: Andrei Borzenkov; Brugnara Daniele
>> Cc: grub-devel@gnu.org
>> Subject: Re: Remotely choose a menu entry
>>
>>
>>
>> I am thinking about a secret key known from both sender and receiver
>> and encode/decode the packet using this, a strong algorithm, of course.
>>
>> Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com>
>> ha
>> scritto:
>>
>> В Sat, 29 Nov 2014 01:10:28 +0000
>> Brugnara Daniele <daniele@brugnara.me> пишет:
>>
>>> Hi all.
>>>
>>> I'm thinking about a system that boots with a wol packet. Who sends
>>> this packet in 99% of cases, is far away from that computer and it
>>> could be useful to boot into a different system instead of the
>>> default one. (please keep in mind that changing the default option in
>>> grub is not a option for this specific use case)
>>>
>>> If a wol can be delivered successfully, an UDP packet containing
>>> simple datas should be enough to achieve this.
>>>
>>> Something like this:
>>>
>>> - MAC: the destination device mac address
>>> - choice: a number (can be empty)
>>> - commandLine: a full commandline (a choice or this..)
>>> - more? I don't know for now..
>>>
>>> This option should be enabled in the grub.conf by the user.
>>>
>>> What do you think about? Could this be useful? Am I missing
>>> something, like a tool that does this automagically?
>>>
>>
>> Yes, it could probably be implemented as a command that loops listening
>> for magic packet and then sets default menu option. Of course, you
>> would need to consider security aspects (who is allowed to send
>> packet, how it is authenticated etc).
>>
>>> I've read about an eth-to-serial but it's not what I want.
>>> PXE or bootp is not an option here. I don't want to manage another
>>> server...
>>>
>>> Thanks for your time.
>>>
>>> Daniele.
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Remotely choose a menu entry
2014-12-01 11:29 ` Andrei Borzenkov
@ 2014-12-01 11:30 ` Parmeshwr_Prasad
0 siblings, 0 replies; 24+ messages in thread
From: Parmeshwr_Prasad @ 2014-12-01 11:30 UTC (permalink / raw)
To: arvidjaar; +Cc: grub-devel
It is multicast but best person will be Daniele :)
-----Original Message-----
From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
Sent: Monday, December 01, 2014 4:59 PM
To: Prasad, Parmeshwr
Cc: The development of GNU GRUB
Subject: Re: Remotely choose a menu entry
On Mon, Dec 1, 2014 at 1:43 PM, <Parmeshwr_Prasad@dell.com> wrote:
>
> If you wanted system to boot with wol package then it should get kernel and initrd from somewhere.
> What is your final goal? How you will get all required binaries ?
>
Are you asking me? I'm not a topic starter.
> Regards
> Parmeshwr
>
> -----Original Message-----
> From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
> Sent: Monday, December 01, 2014 4:08 PM
> To: Prasad, Parmeshwr
> Cc: The development of GNU GRUB
> Subject: Re: Remotely choose a menu entry
>
> On Mon, Dec 1, 2014 at 11:19 AM, <Parmeshwr_Prasad@dell.com> wrote:
>> Is your idea is to send kernel+grub+initramfs through magic packet ?
>
> No.
>
>>
>> if yes then lot of wol design should change first.
>>
>>
>>
>> Regards
>>
>> Parmeshwr
>>
>>
>>
>> From: grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org
>> [mailto:grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org] On
>> Behalf Of Brugnara Daniele
>> Sent: Saturday, November 29, 2014 9:47 PM
>> To: Andrei Borzenkov; Brugnara Daniele
>> Cc: grub-devel@gnu.org
>> Subject: Re: Remotely choose a menu entry
>>
>>
>>
>> I am thinking about a secret key known from both sender and receiver
>> and encode/decode the packet using this, a strong algorithm, of course.
>>
>> Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov
>> <arvidjaar@gmail.com> ha
>> scritto:
>>
>> В Sat, 29 Nov 2014 01:10:28 +0000
>> Brugnara Daniele <daniele@brugnara.me> пишет:
>>
>>> Hi all.
>>>
>>> I'm thinking about a system that boots with a wol packet. Who sends
>>> this packet in 99% of cases, is far away from that computer and it
>>> could be useful to boot into a different system instead of the
>>> default one. (please keep in mind that changing the default option
>>> in grub is not a option for this specific use case)
>>>
>>> If a wol can be delivered successfully, an UDP packet containing
>>> simple datas should be enough to achieve this.
>>>
>>> Something like this:
>>>
>>> - MAC: the destination device mac address
>>> - choice: a number (can be empty)
>>> - commandLine: a full commandline (a choice or this..)
>>> - more? I don't know for now..
>>>
>>> This option should be enabled in the grub.conf by the user.
>>>
>>> What do you think about? Could this be useful? Am I missing
>>> something, like a tool that does this automagically?
>>>
>>
>> Yes, it could probably be implemented as a command that loops
>> listening for magic packet and then sets default menu option. Of
>> course, you would need to consider security aspects (who is allowed
>> to send packet, how it is authenticated etc).
>>
>>> I've read about an eth-to-serial but it's not what I want.
>>> PXE or bootp is not an option here. I don't want to manage another
>>> server...
>>>
>>> Thanks for your time.
>>>
>>> Daniele.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Remotely choose a menu entry
2014-11-29 16:16 ` Brugnara Daniele
2014-12-01 8:19 ` Parmeshwr_Prasad
@ 2014-12-01 23:13 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-12-02 6:22 ` Parmeshwr_Prasad
1 sibling, 1 reply; 24+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2014-12-01 23:13 UTC (permalink / raw)
To: The development of GNU GRUB, Andrei Borzenkov, Brugnara Daniele
[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]
On 29.11.2014 17:16, Brugnara Daniele wrote:
> I am thinking about a secret key known from both sender and receiver and
> encode/decode the packet using this, a strong algorithm, of course.
>
Crypto doesn't work this way. By using weak algorithm your security is
broken but if youre only difference from weak system is a strong
algorithm, your security is probably still nil.
decryption doesn't guarantee integrity. For integrity check you need
MACs or signatures. But even this won't help you for your case. Think of
someone saving traffic for the choice of entry X and then simply
replaying it. It will be valid for entry X.
> Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com
> <mailto:arvidjaar@gmail.com>> ha scritto:
>
> В Sat, 29 Nov 2014 01:10:28 +0000
> Brugnara Daniele <daniele@brugnara.me <mailto:daniele@brugnara.me>>
> пишет:
>
> > Hi all.
> >
> > I'm thinking about a system that boots with a wol packet. Who
> sends this
> > packet in 99% of cases, is far away from that computer and it could be
> > useful to boot into a different system instead of the default one.
> (please
> > keep in mind that changing the default option in grub is not a
> option for
> > this specific use case)
> >
> > If a wol can be delivered successfully, an UDP packet containing
> simple
> > datas should be enough to achieve this.
> >
> > Something like this:
> >
> > - MAC: the destination device mac address
> > - choice: a number (can be empty)
> > - commandLine: a full commandline (a choice or this..)
> > - more? I don't know for now..
> >
> > This option should be enabled in the grub.conf by the user.
> >
> > What do you think about? Could this be useful? Am I missing
> something, like
> > a tool that does this automagically?
> >
>
> Yes, it could probably be implemented as a command that loops listening
> for magic packet and then sets default menu option. Of course, you
> would need to consider security aspects (who is allowed to send
> packet, how it is authenticated etc).
>
> > I've read about an eth-to-serial but it's not what I want.
> > PXE or bootp is not an option here. I don't want to manage another
> > server...
> >
> > Thanks for your time.
> >
> > Daniele.
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Remotely choose a menu entry
2014-12-01 23:13 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2014-12-02 6:22 ` Parmeshwr_Prasad
0 siblings, 0 replies; 24+ messages in thread
From: Parmeshwr_Prasad @ 2014-12-02 6:22 UTC (permalink / raw)
To: grub-devel, arvidjaar, daniele
Hi Daniele,
I will be interested to develop this feature. Please let me know if I can contribute into this.
-Parmeshwr
-----Original Message-----
From: grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org [mailto:grub-devel-bounces+parmeshwr_prasad=dell.com@gnu.org] On Behalf Of Vladimir 'f-coder/phcoder' Serbinenko
Sent: Tuesday, December 02, 2014 4:44 AM
To: The development of GNU GRUB; Andrei Borzenkov; Brugnara Daniele
Subject: Re: Remotely choose a menu entry
On 29.11.2014 17:16, Brugnara Daniele wrote:
> I am thinking about a secret key known from both sender and receiver
> and encode/decode the packet using this, a strong algorithm, of course.
>
Crypto doesn't work this way. By using weak algorithm your security is broken but if youre only difference from weak system is a strong algorithm, your security is probably still nil.
decryption doesn't guarantee integrity. For integrity check you need MACs or signatures. But even this won't help you for your case. Think of someone saving traffic for the choice of entry X and then simply replaying it. It will be valid for entry X.
> Il giorno Sab 29 Nov 2014 17:03 Andrei Borzenkov <arvidjaar@gmail.com
> <mailto:arvidjaar@gmail.com>> ha scritto:
>
> В Sat, 29 Nov 2014 01:10:28 +0000
> Brugnara Daniele <daniele@brugnara.me <mailto:daniele@brugnara.me>>
> пишет:
>
> > Hi all.
> >
> > I'm thinking about a system that boots with a wol packet. Who
> sends this
> > packet in 99% of cases, is far away from that computer and it could be
> > useful to boot into a different system instead of the default one.
> (please
> > keep in mind that changing the default option in grub is not a
> option for
> > this specific use case)
> >
> > If a wol can be delivered successfully, an UDP packet containing
> simple
> > datas should be enough to achieve this.
> >
> > Something like this:
> >
> > - MAC: the destination device mac address
> > - choice: a number (can be empty)
> > - commandLine: a full commandline (a choice or this..)
> > - more? I don't know for now..
> >
> > This option should be enabled in the grub.conf by the user.
> >
> > What do you think about? Could this be useful? Am I missing
> something, like
> > a tool that does this automagically?
> >
>
> Yes, it could probably be implemented as a command that loops listening
> for magic packet and then sets default menu option. Of course, you
> would need to consider security aspects (who is allowed to send
> packet, how it is authenticated etc).
>
> > I've read about an eth-to-serial but it's not what I want.
> > PXE or bootp is not an option here. I don't want to manage another
> > server...
> >
> > Thanks for your time.
> >
> > Daniele.
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Autopilot, a module for remotely doing things
2014-11-29 1:10 Remotely choose a menu entry Brugnara Daniele
2014-11-29 16:03 ` Andrei Borzenkov
@ 2014-12-02 16:22 ` Brugnara Daniele
2014-12-03 7:42 ` Andrei Borzenkov
2014-12-07 16:41 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 2 replies; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-02 16:22 UTC (permalink / raw)
To: Brugnara Daniele, grub-devel
[-- Attachment #1: Type: text/plain, Size: 2568 bytes --]
Here I am again.. I'm studying grub code and thinking about this feature we
are talking about.
A funny name could be "autopilot". I'm thinking this about a big container
where to put more than a "pilot".
Let's see how my mind though this:
AUTOPILOT.mod
|
|____> UDP
|
|____> HTTP Server
|
|____> HTTP Client
|
|____> Serial
Each pilot will do the very same thing: receive/read a small cfg file and
GRUB will do what it must to do.
For a first release, it should be enough to pass:
choice=1
or
choice=Windows 7 (64 bit)
*Why two HTTP?*
It's just an idea. We can think GRUB as a web service that allows it self
being called from any application:
POST grub.local:8080/api/autopilot [!DATA!]
or see GRUB as a client that asks for a file to a centralized server:
http://givemethatfile.please/aa:bb:cc:dd:ee:ff
*Security*
This is a very important thing. Any suggestion will be very appreciated.
*Pilots*
The first release, can have only one pilot. There's no need to develop all
4 and more important, this four are not a final decision. Let's talk about
this.
*GRUB.cfg*
All informations about this module can be stored into grub.cfg or better, a
specific autopilot.cfg but I do not want to add too much complexity.
I'm thinking something about:
[autopilot]
pilots_engaged = UDP[, HTTPSERVER[, SERIAL]]
UDP.port = 1664
HTTPSERVER.port = 8080
SERIAL.port = /dev/ttyUSB0
SERIAL.conf = 57600 8N1
[...]
As always, let's talk about this :)
Daniele.
On Sat Nov 29 2014 at 2:07:31 AM Brugnara Daniele <daniele@brugnara.me>
wrote:
> Hi all.
>
> I'm thinking about a system that boots with a wol packet. Who sends this
> packet in 99% of cases, is far away from that computer and it could be
> useful to boot into a different system instead of the default one. (please
> keep in mind that changing the default option in grub is not a option for
> this specific use case)
>
> If a wol can be delivered successfully, an UDP packet containing simple
> datas should be enough to achieve this.
>
> Something like this:
>
> - MAC: the destination device mac address
> - choice: a number (can be empty)
> - commandLine: a full commandline (a choice or this..)
> - more? I don't know for now..
>
> This option should be enabled in the grub.conf by the user.
>
> What do you think about? Could this be useful? Am I missing something,
> like a tool that does this automagically?
>
> I've read about an eth-to-serial but it's not what I want.
> PXE or bootp is not an option here. I don't want to manage another
> server...
>
> Thanks for your time.
>
> Daniele.
>
>
[-- Attachment #2: Type: text/html, Size: 3830 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-02 16:22 ` Autopilot, a module for remotely doing things Brugnara Daniele
@ 2014-12-03 7:42 ` Andrei Borzenkov
2014-12-03 8:18 ` Brugnara Daniele
2014-12-07 16:41 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 1 reply; 24+ messages in thread
From: Andrei Borzenkov @ 2014-12-03 7:42 UTC (permalink / raw)
To: The development of GNU GRUB; +Cc: Brugnara Daniele
On Tue, Dec 2, 2014 at 7:22 PM, Brugnara Daniele <daniele@brugnara.me> wrote:
> Here I am again.. I'm studying grub code and thinking about this feature we
> are talking about.
> A funny name could be "autopilot". I'm thinking this about a big container
> where to put more than a "pilot".
>
...
> Each pilot will do the very same thing: receive/read a small cfg file and
> GRUB will do what it must to do.
>
This does not need any module.
source (http,server-or-IP)/extra.cfg
enclose in "set check_signatures=enforce; ...; set check_signatures="
to ensure file verification.
> For a first release, it should be enough to pass:
>
> choice=1
>
> or
>
> choice=Windows 7 (64 bit)
>
> Why two HTTP?
>
> It's just an idea. We can think GRUB as a web service that allows it self
> being called from any application:
>
> POST grub.local:8080/api/autopilot [!DATA!]
>
> or see GRUB as a client that asks for a file to a centralized server:
>
> http://givemethatfile.please/aa:bb:cc:dd:ee:ff
>
> Security
>
> This is a very important thing. Any suggestion will be very appreciated.
>
> Pilots
>
> The first release, can have only one pilot. There's no need to develop all 4
> and more important, this four are not a final decision. Let's talk about
> this.
>
> GRUB.cfg
>
> All informations about this module can be stored into grub.cfg or better, a
> specific autopilot.cfg but I do not want to add too much complexity.
>
> I'm thinking something about:
>
> [autopilot]
> pilots_engaged = UDP[, HTTPSERVER[, SERIAL]]
>
> UDP.port = 1664
> HTTPSERVER.port = 8080
> SERIAL.port = /dev/ttyUSB0
> SERIAL.conf = 57600 8N1
> [...]
>
>
> As always, let's talk about this :)
>
> Daniele.
>
>
> On Sat Nov 29 2014 at 2:07:31 AM Brugnara Daniele <daniele@brugnara.me>
> wrote:
>>
>> Hi all.
>>
>> I'm thinking about a system that boots with a wol packet. Who sends this
>> packet in 99% of cases, is far away from that computer and it could be
>> useful to boot into a different system instead of the default one. (please
>> keep in mind that changing the default option in grub is not a option for
>> this specific use case)
>>
>> If a wol can be delivered successfully, an UDP packet containing simple
>> datas should be enough to achieve this.
>>
>> Something like this:
>>
>> - MAC: the destination device mac address
>> - choice: a number (can be empty)
>> - commandLine: a full commandline (a choice or this..)
>> - more? I don't know for now..
>>
>> This option should be enabled in the grub.conf by the user.
>>
>> What do you think about? Could this be useful? Am I missing something,
>> like a tool that does this automagically?
>>
>> I've read about an eth-to-serial but it's not what I want.
>> PXE or bootp is not an option here. I don't want to manage another
>> server...
>>
>> Thanks for your time.
>>
>> Daniele.
>>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 7:42 ` Andrei Borzenkov
@ 2014-12-03 8:18 ` Brugnara Daniele
2014-12-03 8:31 ` Andrei Borzenkov
0 siblings, 1 reply; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-03 8:18 UTC (permalink / raw)
To: Andrei Borzenkov, The development of GNU GRUB; +Cc: Brugnara Daniele
[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]
This seems a very nice feature but I'm unable to make it work. I'm having
this error:
root@hulk:/home/vrut/dev/grub# update-grub
/usr/sbin/grub-mkconfig: 34: /etc/default/grub: source: not found
Am I missing something?
On Wed Dec 03 2014 at 8:42:36 AM Andrei Borzenkov <arvidjaar@gmail.com>
wrote:
> On Tue, Dec 2, 2014 at 7:22 PM, Brugnara Daniele <daniele@brugnara.me>
> wrote:
> > Here I am again.. I'm studying grub code and thinking about this feature
> we
> > are talking about.
> > A funny name could be "autopilot". I'm thinking this about a big
> container
> > where to put more than a "pilot".
> >
> ...
> > Each pilot will do the very same thing: receive/read a small cfg file and
> > GRUB will do what it must to do.
> >
>
> This does not need any module.
>
> source (http,server-or-IP)/extra.cfg
>
> enclose in "set check_signatures=enforce; ...; set check_signatures="
> to ensure file verification.
>
> > For a first release, it should be enough to pass:
> >
> > choice=1
> >
> > or
> >
> > choice=Windows 7 (64 bit)
> >
> > Why two HTTP?
> >
> > It's just an idea. We can think GRUB as a web service that allows it self
> > being called from any application:
> >
> > POST grub.local:8080/api/autopilot [!DATA!]
> >
> > or see GRUB as a client that asks for a file to a centralized server:
> >
> > http://givemethatfile.please/aa:bb:cc:dd:ee:ff
> >
> > Security
> >
> > This is a very important thing. Any suggestion will be very appreciated.
> >
> > Pilots
> >
> > The first release, can have only one pilot. There's no need to develop
> all 4
> > and more important, this four are not a final decision. Let's talk about
> > this.
> >
> > GRUB.cfg
> >
> > All informations about this module can be stored into grub.cfg or
> better, a
> > specific autopilot.cfg but I do not want to add too much complexity.
> >
> > I'm thinking something about:
> >
> > [autopilot]
> > pilots_engaged = UDP[, HTTPSERVER[, SERIAL]]
> >
> > UDP.port = 1664
> > HTTPSERVER.port = 8080
> > SERIAL.port = /dev/ttyUSB0
> > SERIAL.conf = 57600 8N1
> > [...]
> >
> >
> > As always, let's talk about this :)
> >
> > Daniele.
> >
> >
> > On Sat Nov 29 2014 at 2:07:31 AM Brugnara Daniele <daniele@brugnara.me>
> > wrote:
> >>
> >> Hi all.
> >>
> >> I'm thinking about a system that boots with a wol packet. Who sends this
> >> packet in 99% of cases, is far away from that computer and it could be
> >> useful to boot into a different system instead of the default one.
> (please
> >> keep in mind that changing the default option in grub is not a option
> for
> >> this specific use case)
> >>
> >> If a wol can be delivered successfully, an UDP packet containing simple
> >> datas should be enough to achieve this.
> >>
> >> Something like this:
> >>
> >> - MAC: the destination device mac address
> >> - choice: a number (can be empty)
> >> - commandLine: a full commandline (a choice or this..)
> >> - more? I don't know for now..
> >>
> >> This option should be enabled in the grub.conf by the user.
> >>
> >> What do you think about? Could this be useful? Am I missing something,
> >> like a tool that does this automagically?
> >>
> >> I've read about an eth-to-serial but it's not what I want.
> >> PXE or bootp is not an option here. I don't want to manage another
> >> server...
> >>
> >> Thanks for your time.
> >>
> >> Daniele.
> >>
> >
> > _______________________________________________
> > Grub-devel mailing list
> > Grub-devel@gnu.org
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
>
[-- Attachment #2: Type: text/html, Size: 4921 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 8:18 ` Brugnara Daniele
@ 2014-12-03 8:31 ` Andrei Borzenkov
2014-12-03 17:00 ` Brugnara Daniele
0 siblings, 1 reply; 24+ messages in thread
From: Andrei Borzenkov @ 2014-12-03 8:31 UTC (permalink / raw)
To: Brugnara Daniele; +Cc: The development of GNU GRUB
On Wed, Dec 3, 2014 at 11:18 AM, Brugnara Daniele <daniele@brugnara.me> wrote:
> This seems a very nice feature but I'm unable to make it work. I'm having
> this error:
>
> root@hulk:/home/vrut/dev/grub# update-grub
> /usr/sbin/grub-mkconfig: 34: /etc/default/grub: source: not found
>
source is grub command that should be executed at run time. If you
want to use grub-mkconfig to add this command, see
/etc/grub.d/40_custom
> Am I missing something?
>
> On Wed Dec 03 2014 at 8:42:36 AM Andrei Borzenkov <arvidjaar@gmail.com>
> wrote:
>>
>> On Tue, Dec 2, 2014 at 7:22 PM, Brugnara Daniele <daniele@brugnara.me>
>> wrote:
>> > Here I am again.. I'm studying grub code and thinking about this feature
>> > we
>> > are talking about.
>> > A funny name could be "autopilot". I'm thinking this about a big
>> > container
>> > where to put more than a "pilot".
>> >
>> ...
>> > Each pilot will do the very same thing: receive/read a small cfg file
>> > and
>> > GRUB will do what it must to do.
>> >
>>
>> This does not need any module.
>>
>> source (http,server-or-IP)/extra.cfg
>>
>> enclose in "set check_signatures=enforce; ...; set check_signatures="
>> to ensure file verification.
>>
>> > For a first release, it should be enough to pass:
>> >
>> > choice=1
>> >
>> > or
>> >
>> > choice=Windows 7 (64 bit)
>> >
>> > Why two HTTP?
>> >
>> > It's just an idea. We can think GRUB as a web service that allows it
>> > self
>> > being called from any application:
>> >
>> > POST grub.local:8080/api/autopilot [!DATA!]
>> >
>> > or see GRUB as a client that asks for a file to a centralized server:
>> >
>> > http://givemethatfile.please/aa:bb:cc:dd:ee:ff
>> >
>> > Security
>> >
>> > This is a very important thing. Any suggestion will be very appreciated.
>> >
>> > Pilots
>> >
>> > The first release, can have only one pilot. There's no need to develop
>> > all 4
>> > and more important, this four are not a final decision. Let's talk about
>> > this.
>> >
>> > GRUB.cfg
>> >
>> > All informations about this module can be stored into grub.cfg or
>> > better, a
>> > specific autopilot.cfg but I do not want to add too much complexity.
>> >
>> > I'm thinking something about:
>> >
>> > [autopilot]
>> > pilots_engaged = UDP[, HTTPSERVER[, SERIAL]]
>> >
>> > UDP.port = 1664
>> > HTTPSERVER.port = 8080
>> > SERIAL.port = /dev/ttyUSB0
>> > SERIAL.conf = 57600 8N1
>> > [...]
>> >
>> >
>> > As always, let's talk about this :)
>> >
>> > Daniele.
>> >
>> >
>> > On Sat Nov 29 2014 at 2:07:31 AM Brugnara Daniele <daniele@brugnara.me>
>> > wrote:
>> >>
>> >> Hi all.
>> >>
>> >> I'm thinking about a system that boots with a wol packet. Who sends
>> >> this
>> >> packet in 99% of cases, is far away from that computer and it could be
>> >> useful to boot into a different system instead of the default one.
>> >> (please
>> >> keep in mind that changing the default option in grub is not a option
>> >> for
>> >> this specific use case)
>> >>
>> >> If a wol can be delivered successfully, an UDP packet containing simple
>> >> datas should be enough to achieve this.
>> >>
>> >> Something like this:
>> >>
>> >> - MAC: the destination device mac address
>> >> - choice: a number (can be empty)
>> >> - commandLine: a full commandline (a choice or this..)
>> >> - more? I don't know for now..
>> >>
>> >> This option should be enabled in the grub.conf by the user.
>> >>
>> >> What do you think about? Could this be useful? Am I missing something,
>> >> like a tool that does this automagically?
>> >>
>> >> I've read about an eth-to-serial but it's not what I want.
>> >> PXE or bootp is not an option here. I don't want to manage another
>> >> server...
>> >>
>> >> Thanks for your time.
>> >>
>> >> Daniele.
>> >>
>> >
>> > _______________________________________________
>> > Grub-devel mailing list
>> > Grub-devel@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/grub-devel
>> >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 8:31 ` Andrei Borzenkov
@ 2014-12-03 17:00 ` Brugnara Daniele
2014-12-03 18:03 ` Alan Perry
0 siblings, 1 reply; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-03 17:00 UTC (permalink / raw)
To: Andrei Borzenkov, Brugnara Daniele; +Cc: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 4965 bytes --]
I've tried a lot without success. There's no documentation about (http) in
exception for a little entry in this documentation (
https://www.gnu.org/software/grub/manual/html_node/Device-syntax.html)
where is said about it but no details on how to mount or use this "device".
What I have also tried is:
insmod net
insmod http
net_ls_addr (gives no results)
and any of this commands gives no results (http server is never called, I'm
sure about this)
source (http,http://192.168.1.70:1273)/
source (http:http://192.168.1.70:1273)/
source (http,192.168.1.70,1273)/
source (http:192.168.1.70:1273:/)
[...]
Am I missing something? The lack of documentation doesn't help on this.
Many thanks for your time.
On Wed Dec 03 2014 at 9:31:34 AM Andrei Borzenkov <arvidjaar@gmail.com>
wrote:
> On Wed, Dec 3, 2014 at 11:18 AM, Brugnara Daniele <daniele@brugnara.me>
> wrote:
> > This seems a very nice feature but I'm unable to make it work. I'm having
> > this error:
> >
> > root@hulk:/home/vrut/dev/grub# update-grub
> > /usr/sbin/grub-mkconfig: 34: /etc/default/grub: source: not found
> >
>
> source is grub command that should be executed at run time. If you
> want to use grub-mkconfig to add this command, see
> /etc/grub.d/40_custom
>
> > Am I missing something?
> >
> > On Wed Dec 03 2014 at 8:42:36 AM Andrei Borzenkov <arvidjaar@gmail.com>
> > wrote:
> >>
> >> On Tue, Dec 2, 2014 at 7:22 PM, Brugnara Daniele <daniele@brugnara.me>
> >> wrote:
> >> > Here I am again.. I'm studying grub code and thinking about this
> feature
> >> > we
> >> > are talking about.
> >> > A funny name could be "autopilot". I'm thinking this about a big
> >> > container
> >> > where to put more than a "pilot".
> >> >
> >> ...
> >> > Each pilot will do the very same thing: receive/read a small cfg file
> >> > and
> >> > GRUB will do what it must to do.
> >> >
> >>
> >> This does not need any module.
> >>
> >> source (http,server-or-IP)/extra.cfg
> >>
> >> enclose in "set check_signatures=enforce; ...; set check_signatures="
> >> to ensure file verification.
> >>
> >> > For a first release, it should be enough to pass:
> >> >
> >> > choice=1
> >> >
> >> > or
> >> >
> >> > choice=Windows 7 (64 bit)
> >> >
> >> > Why two HTTP?
> >> >
> >> > It's just an idea. We can think GRUB as a web service that allows it
> >> > self
> >> > being called from any application:
> >> >
> >> > POST grub.local:8080/api/autopilot [!DATA!]
> >> >
> >> > or see GRUB as a client that asks for a file to a centralized server:
> >> >
> >> > http://givemethatfile.please/aa:bb:cc:dd:ee:ff
> >> >
> >> > Security
> >> >
> >> > This is a very important thing. Any suggestion will be very
> appreciated.
> >> >
> >> > Pilots
> >> >
> >> > The first release, can have only one pilot. There's no need to develop
> >> > all 4
> >> > and more important, this four are not a final decision. Let's talk
> about
> >> > this.
> >> >
> >> > GRUB.cfg
> >> >
> >> > All informations about this module can be stored into grub.cfg or
> >> > better, a
> >> > specific autopilot.cfg but I do not want to add too much complexity.
> >> >
> >> > I'm thinking something about:
> >> >
> >> > [autopilot]
> >> > pilots_engaged = UDP[, HTTPSERVER[, SERIAL]]
> >> >
> >> > UDP.port = 1664
> >> > HTTPSERVER.port = 8080
> >> > SERIAL.port = /dev/ttyUSB0
> >> > SERIAL.conf = 57600 8N1
> >> > [...]
> >> >
> >> >
> >> > As always, let's talk about this :)
> >> >
> >> > Daniele.
> >> >
> >> >
> >> > On Sat Nov 29 2014 at 2:07:31 AM Brugnara Daniele <
> daniele@brugnara.me>
> >> > wrote:
> >> >>
> >> >> Hi all.
> >> >>
> >> >> I'm thinking about a system that boots with a wol packet. Who sends
> >> >> this
> >> >> packet in 99% of cases, is far away from that computer and it could
> be
> >> >> useful to boot into a different system instead of the default one.
> >> >> (please
> >> >> keep in mind that changing the default option in grub is not a option
> >> >> for
> >> >> this specific use case)
> >> >>
> >> >> If a wol can be delivered successfully, an UDP packet containing
> simple
> >> >> datas should be enough to achieve this.
> >> >>
> >> >> Something like this:
> >> >>
> >> >> - MAC: the destination device mac address
> >> >> - choice: a number (can be empty)
> >> >> - commandLine: a full commandline (a choice or this..)
> >> >> - more? I don't know for now..
> >> >>
> >> >> This option should be enabled in the grub.conf by the user.
> >> >>
> >> >> What do you think about? Could this be useful? Am I missing
> something,
> >> >> like a tool that does this automagically?
> >> >>
> >> >> I've read about an eth-to-serial but it's not what I want.
> >> >> PXE or bootp is not an option here. I don't want to manage another
> >> >> server...
> >> >>
> >> >> Thanks for your time.
> >> >>
> >> >> Daniele.
> >> >>
> >> >
> >> > _______________________________________________
> >> > Grub-devel mailing list
> >> > Grub-devel@gnu.org
> >> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >> >
>
[-- Attachment #2: Type: text/html, Size: 7771 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 17:00 ` Brugnara Daniele
@ 2014-12-03 18:03 ` Alan Perry
2014-12-03 20:03 ` Brugnara Daniele
0 siblings, 1 reply; 24+ messages in thread
From: Alan Perry @ 2014-12-03 18:03 UTC (permalink / raw)
To: The development of GNU GRUB; +Cc: Andrei Borzenkov, Brugnara Daniele
> On Dec 3, 2014, at 9:00 AM, Brugnara Daniele <daniele@brugnara.me> wrote:
>
> source (http,http://192.168.1.70:1273)/
> source (http:http://192.168.1.70:1273)/
> source (http,192.168.1.70,1273)/
> source (http:192.168.1.70:1273:/)
> [...]
>
>
The syntax for a net device is (<protocol>, <server>). <protocol> in your case would be 'http'. <server> would be 192.168.1.170. The http module is hard-coded to use port 80.
I am in the process of extending the syntax to allow the port to be specified (with syntax (<protocol>, <server>, <port>)). Working through a bug in my code.
alan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 18:03 ` Alan Perry
@ 2014-12-03 20:03 ` Brugnara Daniele
2014-12-03 20:34 ` Brugnara Daniele
2014-12-04 3:41 ` Andrei Borzenkov
0 siblings, 2 replies; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-03 20:03 UTC (permalink / raw)
To: Alan Perry, The development of GNU GRUB
Cc: Andrei Borzenkov, Brugnara Daniele
[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]
Do I have to initialize the network or grub does it self? I suppose that
calling *net_ls_cards* something should be printed out but this is not true
in my case.
*FOR_NET_CARDS* macro doesn't output any cards.
In the source code, I've found that there is a function *grub_net_card_register
*and for what I have understood, this should be called somewhere. I think
that this is done by the modules: *efinet, emunet, ofnet, ubootnet *and*
pxe*. I'm trying to insmod-ding *ofnet* but with no fortune.
If I'm doing something stupid, please tell me. I don't want to waste your
time.
Thanks.
On Wed Dec 03 2014 at 7:03:19 PM Alan Perry <aperry@snowmoose.com> wrote:
>
>
> > On Dec 3, 2014, at 9:00 AM, Brugnara Daniele <daniele@brugnara.me>
> wrote:
> >
> > source (http,http://192.168.1.70:1273)/
> > source (http:http://192.168.1.70:1273)/
> > source (http,192.168.1.70,1273)/
> > source (http:192.168.1.70:1273:/)
> > [...]
> >
> >
>
> The syntax for a net device is (<protocol>, <server>). <protocol> in your
> case would be 'http'. <server> would be 192.168.1.170. The http module is
> hard-coded to use port 80.
>
> I am in the process of extending the syntax to allow the port to be
> specified (with syntax (<protocol>, <server>, <port>)). Working through a
> bug in my code.
>
> alan
>
>
[-- Attachment #2: Type: text/html, Size: 1954 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 20:03 ` Brugnara Daniele
@ 2014-12-03 20:34 ` Brugnara Daniele
2014-12-04 6:26 ` Andrei Borzenkov
2014-12-04 3:41 ` Andrei Borzenkov
1 sibling, 1 reply; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-03 20:34 UTC (permalink / raw)
To: Brugnara Daniele, Alan Perry, The development of GNU GRUB
Cc: Andrei Borzenkov
[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]
I think I've found the problem. I'm in virtualbox and no compatible cards
are found. I'll try with a real pc with a real nic and I'll let you know my
progress.
Daniele.
On Wed Dec 03 2014 at 9:03:05 PM Brugnara Daniele <daniele@brugnara.me>
wrote:
> Do I have to initialize the network or grub does it self? I suppose that
> calling *net_ls_cards* something should be printed out but this is not
> true in my case.
> *FOR_NET_CARDS* macro doesn't output any cards.
> In the source code, I've found that there is a function *grub_net_card_register
> *and for what I have understood, this should be called somewhere. I think
> that this is done by the modules: *efinet, emunet, ofnet, ubootnet *and*
> pxe*. I'm trying to insmod-ding *ofnet* but with no fortune.
> If I'm doing something stupid, please tell me. I don't want to waste your
> time.
>
> Thanks.
>
>
>
>
> On Wed Dec 03 2014 at 7:03:19 PM Alan Perry <aperry@snowmoose.com> wrote:
>
>>
>>
>> > On Dec 3, 2014, at 9:00 AM, Brugnara Daniele <daniele@brugnara.me>
>> wrote:
>> >
>> > source (http,http://192.168.1.70:1273)/
>> > source (http:http://192.168.1.70:1273)/
>> > source (http,192.168.1.70,1273)/
>> > source (http:192.168.1.70:1273:/)
>> > [...]
>> >
>> >
>>
>> The syntax for a net device is (<protocol>, <server>). <protocol> in
>> your case would be 'http'. <server> would be 192.168.1.170. The http
>> module is hard-coded to use port 80.
>>
>> I am in the process of extending the syntax to allow the port to be
>> specified (with syntax (<protocol>, <server>, <port>)). Working through a
>> bug in my code.
>>
>> alan
>>
>>
[-- Attachment #2: Type: text/html, Size: 2450 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 20:34 ` Brugnara Daniele
@ 2014-12-04 6:26 ` Andrei Borzenkov
0 siblings, 0 replies; 24+ messages in thread
From: Andrei Borzenkov @ 2014-12-04 6:26 UTC (permalink / raw)
To: Brugnara Daniele; +Cc: Alan Perry, The development of GNU GRUB
On Wed, Dec 3, 2014 at 11:34 PM, Brugnara Daniele <daniele@brugnara.me> wrote:
> I think I've found the problem. I'm in virtualbox and no compatible cards
> are found. I'll try with a real pc with a real nic and I'll let you know my
> progress.
Are you on legacy BIOS? GRUB does not have hardware NIC drivers; it
relies on networking support provided by platform firmware. In case of
legacy BIOS the only network stack is PXE and it is available only
when grub was booted via PXE.
> Daniele.
>
> On Wed Dec 03 2014 at 9:03:05 PM Brugnara Daniele <daniele@brugnara.me>
> wrote:
>>
>> Do I have to initialize the network or grub does it self? I suppose that
>> calling net_ls_cards something should be printed out but this is not true in
>> my case.
>> FOR_NET_CARDS macro doesn't output any cards.
>> In the source code, I've found that there is a function
>> grub_net_card_register and for what I have understood, this should be called
>> somewhere. I think that this is done by the modules: efinet, emunet, ofnet,
>> ubootnet and pxe. I'm trying to insmod-ding ofnet but with no fortune.
>> If I'm doing something stupid, please tell me. I don't want to waste your
>> time.
>>
>> Thanks.
>>
>>
>>
>>
>> On Wed Dec 03 2014 at 7:03:19 PM Alan Perry <aperry@snowmoose.com> wrote:
>>>
>>>
>>>
>>> > On Dec 3, 2014, at 9:00 AM, Brugnara Daniele <daniele@brugnara.me>
>>> > wrote:
>>> >
>>> > source (http,http://192.168.1.70:1273)/
>>> > source (http:http://192.168.1.70:1273)/
>>> > source (http,192.168.1.70,1273)/
>>> > source (http:192.168.1.70:1273:/)
>>> > [...]
>>> >
>>> >
>>>
>>> The syntax for a net device is (<protocol>, <server>). <protocol> in
>>> your case would be 'http'. <server> would be 192.168.1.170. The http module
>>> is hard-coded to use port 80.
>>>
>>> I am in the process of extending the syntax to allow the port to be
>>> specified (with syntax (<protocol>, <server>, <port>)). Working through a
>>> bug in my code.
>>>
>>> alan
>>>
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-03 20:03 ` Brugnara Daniele
2014-12-03 20:34 ` Brugnara Daniele
@ 2014-12-04 3:41 ` Andrei Borzenkov
1 sibling, 0 replies; 24+ messages in thread
From: Andrei Borzenkov @ 2014-12-04 3:41 UTC (permalink / raw)
To: Brugnara Daniele; +Cc: Alan Perry, The development of GNU GRUB
В Wed, 03 Dec 2014 20:03:04 +0000
Brugnara Daniele <daniele@brugnara.me> пишет:
> Do I have to initialize the network or grub does it self?
If grub is PXE booted, networking is already loaded and at boot
interface is set up. If grub is loaded from disk, you have to do it
yourself. net_bootp would try to autoconfigure all available adapters
via DHCP. See also grub info for description.
> I suppose that
> calling *net_ls_cards* something should be printed out but this is not true
> in my case.
> *FOR_NET_CARDS* macro doesn't output any cards.
> In the source code, I've found that there is a function *grub_net_card_register
> *and for what I have understood, this should be called somewhere. I think
> that this is done by the modules: *efinet, emunet, ofnet, ubootnet *and*
> pxe*. I'm trying to insmod-ding *ofnet* but with no fortune.
> If I'm doing something stupid, please tell me. I don't want to waste your
> time.
>
> Thanks.
>
>
>
>
> On Wed Dec 03 2014 at 7:03:19 PM Alan Perry <aperry@snowmoose.com> wrote:
>
> >
> >
> > > On Dec 3, 2014, at 9:00 AM, Brugnara Daniele <daniele@brugnara.me>
> > wrote:
> > >
> > > source (http,http://192.168.1.70:1273)/
> > > source (http:http://192.168.1.70:1273)/
> > > source (http,192.168.1.70,1273)/
> > > source (http:192.168.1.70:1273:/)
> > > [...]
> > >
> > >
> >
> > The syntax for a net device is (<protocol>, <server>). <protocol> in your
> > case would be 'http'. <server> would be 192.168.1.170. The http module is
> > hard-coded to use port 80.
> >
> > I am in the process of extending the syntax to allow the port to be
> > specified (with syntax (<protocol>, <server>, <port>)). Working through a
> > bug in my code.
> >
> > alan
> >
> >
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Autopilot, a module for remotely doing things
2014-12-02 16:22 ` Autopilot, a module for remotely doing things Brugnara Daniele
2014-12-03 7:42 ` Andrei Borzenkov
@ 2014-12-07 16:41 ` Vladimir 'φ-coder/phcoder' Serbinenko
1 sibling, 0 replies; 24+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2014-12-07 16:41 UTC (permalink / raw)
To: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 873 bytes --]
On 02.12.2014 17:22, Brugnara Daniele wrote:
> Here I am again.. I'm studying grub code and thinking about this feature
> we are talking about.
> A funny name could be "autopilot". I'm thinking this about a big
> container where to put more than a "pilot".
>
Way too monolithic. Too much functionality jumbled in one module.
> Let's see how my mind though this:
>
> AUTOPILOT.mod
> |
> |____> UDP
> |
I'd prefer to stic to known protocols rather than inventing new ones.
> |____> HTTP Server
> |
this one may be worthwhile. But telnet is easier for similar functionality
> |____> HTTP Client
> |
Already covered by (http,...)/.... Please improve documentation rather
than adding new ways of doing things.
> |____> Serial
Already covered by serial console. If you need to transfer files via
serial, kermit is a way to go, not custom protocols.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* RE: Remotely choose a menu entry
@ 2014-12-01 12:03 Brugnara Daniele
2014-12-01 16:43 ` Jonathan McCune
0 siblings, 1 reply; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-01 12:03 UTC (permalink / raw)
To: Parmeshwr_Prasad, grub-devel
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
You have simply misunderstood me. I'm trying to explain deeply :)
When grub starts, it asks for a choice, lets take this, as an example:
1) Linux
2) Linux (mem test ecc)
3) Windows 7
4) Windows Server 2000
I want grub to listen for an encrypted UDP packet that emulate an human
choice.
Continuing the example:
1) send a WOL to aa:bb:cc:dd:ee:ff
2) start an UDP loop to the same mac address, to start the 3rd grub menu'
choice (in this example, windows 7)
3) when grub receive that UDP packet, successfully decrypts it and it is
sure that this packet is trusted (rsa or what you want), selects that menu
choice
4) grub boots the selected item.
No files are passed in any way. I'm telling GRUB to boot a specific and
preconfigured entry.
In the UDP packet, I'm thinking to insert a grub command line. This is very
similar to pressing E when grub asks what to do at boot.
I'm not sure of why you have wrote about kernel files. I never wrote about
sending files because this should be done by a PXE or bootp but this is NOT
my goal.
Another very useful thing, should be that GRUB sends an encrypted UDP
packet with his menu configuration in order to do a reasonable choice from
a third party application.
Many thanks for your time.
Daniele.
[-- Attachment #2: Type: text/html, Size: 1645 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Remotely choose a menu entry
2014-12-01 12:03 Remotely choose a menu entry Brugnara Daniele
@ 2014-12-01 16:43 ` Jonathan McCune
2014-12-01 18:59 ` Brugnara Daniele
0 siblings, 1 reply; 24+ messages in thread
From: Jonathan McCune @ 2014-12-01 16:43 UTC (permalink / raw)
To: The development of GNU GRUB, daniele
[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]
Some half-baked thoughts:
On Mon, Dec 1, 2014 at 4:03 AM, Brugnara Daniele <daniele@brugnara.me>
wrote:
> You have simply misunderstood me. I'm trying to explain deeply :)
>
> When grub starts, it asks for a choice, lets take this, as an example:
>
> 1) Linux
> 2) Linux (mem test ecc)
> 3) Windows 7
> 4) Windows Server 2000
>
> I want grub to listen for an encrypted UDP packet that emulate an human
> choice.
>
> Continuing the example:
>
> 1) send a WOL to aa:bb:cc:dd:ee:ff
> 2) start an UDP loop to the same mac address, to start the 3rd grub menu'
> choice (in this example, windows 7)
>
This "push" model doesn't seem like a good idea to me. I would suggest
configuring GRUB to query (perhaps HTTP GET) something centralized, from
which it can read an index (0-3, or 1-4, or whatever) or a label ("Windows
Server 2000", etc). Then, the machine can boot upon receiving WOL, and then
execute its local configuration file. Depending on your threat model, it
might even be fine not to authenticate the central server, if their
behavior is confined to selecting from among existing entries.
I haven't played with GRUB's network-aware capabilities, but the .cfg file
language is likely expressive enough to do something like this. If a new
command is needed, I suggest something like a constrained assignment to an
environment variable. E.g., net_load_env_or_timeout LABEL_FROM_NET 10
example.com:8080
The idea being that the command will either timeout after 10 seconds, fail
because example.com:8080 returned something nonsensical, or assign a new
value to LABEL_FROM_NET. HTTP GET over TCP as the network protocol. Typical
GRUB scripting can then be used depending on the value of $LABEL_FROM_NET
(it would select from among the entries in the list, or fail). You can also
work in one-time boot / savedefault, etc. Mimic the existing load_env
functionality as much as possible.
If everything fails, then fallback to the local menu as usual.
3) when grub receives that UDP packet, successfully decrypts it and it is
> sure that this packet is trusted (rsa or what you want), selects that menu
> choice
>
If you want to authenticate I encourage you to stick with the existing
OpenPGP (RFC4880) functionality. Maybe
net_authenticated_load_env_or_timeout, where the requests are just http
GETs and a signature over the possible new environment file, and a detached
signature file.
4) grub boots the selected item.
>
> No files are passed in any way. I'm telling GRUB to boot a specific and
> preconfigured entry.
>
I think the proposed "simplification" of not passing files is not actually
a simplification. Not passing files full of executable code is good. But
passing a little file foo.cfg with some VAR_NAME="some value", with perhaps
also a foo.cfg.sig sitting on the fileserver, where the .cfg file will only
lead to setting environment variables if it is properly signed, and even
then only set whitelisted variables, seems promising.
In the UDP packet, I'm thinking to insert a grub command line. This is very
> similar to pressing E when grub asks what to do at boot.
>
I don't think it is the best choice to mimic user input. It is much safer
to select from among existing entries.
> I'm not sure of why you have wrote about kernel files. I never wrote about
> sending files because this should be done by a PXE or bootp but this is NOT
> my goal.
>
> Another very useful thing, should be that GRUB sends an encrypted UDP
> packet with his menu configuration in order to do a reasonable choice from
> a third party application.
>
> Many thanks for your time.
>
> Daniele.
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
[-- Attachment #2: Type: text/html, Size: 5995 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: Remotely choose a menu entry
2014-12-01 16:43 ` Jonathan McCune
@ 2014-12-01 18:59 ` Brugnara Daniele
0 siblings, 0 replies; 24+ messages in thread
From: Brugnara Daniele @ 2014-12-01 18:59 UTC (permalink / raw)
To: Jonathan McCune; +Cc: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 4385 bytes --]
See inline.
Il 01/Dic/2014 17:43 "Jonathan McCune" <jonmccune@google.com> ha scritto:
>
> Some half-baked thoughts:
>
> On Mon, Dec 1, 2014 at 4:03 AM, Brugnara Daniele <daniele@brugnara.me>
wrote:
>>
>> You have simply misunderstood me. I'm trying to explain deeply :)
>>
>> When grub starts, it asks for a choice, lets take this, as an example:
>>
>> 1) Linux
>> 2) Linux (mem test ecc)
>> 3) Windows 7
>> 4) Windows Server 2000
>>
>> I want grub to listen for an encrypted UDP packet that emulate an human
choice.
>>
>> Continuing the example:
>>
>> 1) send a WOL to aa:bb:cc:dd:ee:ff
>> 2) start an UDP loop to the same mac address, to start the 3rd grub
menu' choice (in this example, windows 7)
>
>
> This "push" model doesn't seem like a good idea to me. I would suggest
configuring GRUB to query (perhaps HTTP GET) something centralized, from
which it can read an index (0-3, or 1-4, or whatever) or a label ("Windows
Server 2000", etc). Then, the machine can boot upon receiving WOL, and then
execute its local configuration file. Depending on your threat model, it
might even be fine not to authenticate the central server, if their
behavior is confined to selecting from among existing entries.
I really like this. My doubts are about the protocol required to contacting
an http server. This requires an Ip. Does grub have an ip address? If yes,
we can think about exposing a sort of API from grub allowing a better
security and control about this. I am also thinking if this is
affordable...
>
> I haven't played with GRUB's network-aware capabilities, but the .cfg
file language is likely expressive enough to do something like this. If a
new command is needed, I suggest something like a constrained assignment to
an environment variable. E.g., net_load_env_or_timeout LABEL_FROM_NET 10
example.com:8080
>
> The idea being that the command will either timeout after 10 seconds,
fail because example.com:8080 returned something nonsensical, or assign a
new value to LABEL_FROM_NET. HTTP GET over TCP as the network protocol.
Typical GRUB scripting can then be used depending on the value of
$LABEL_FROM_NET (it would select from among the entries in the list, or
fail). You can also work in one-time boot / savedefault, etc. Mimic the
existing load_env functionality as much as possible.
>
> If everything fails, then fallback to the local menu as usual.
Absolutely yes.
>
>> 3) when grub receives that UDP packet, successfully decrypts it and it
is sure that this packet is trusted (rsa or what you want), selects that
menu choice
>
>
> If you want to authenticate I encourage you to stick with the existing
OpenPGP (RFC4880) functionality. Maybe
net_authenticated_load_env_or_timeout, where the requests are just http
GETs and a signature over the possible new environment file, and a detached
signature file.
Thanks for the hint.
>
>> 4) grub boots the selected item.
>>
>> No files are passed in any way. I'm telling GRUB to boot a specific and
preconfigured entry.
>
>
> I think the proposed "simplification" of not passing files is not
actually a simplification. Not passing files full of executable code is
good. But passing a little file foo.cfg with some VAR_NAME="some value",
with perhaps also a foo.cfg.sig sitting on the fileserver, where the .cfg
file will only lead to setting environment variables if it is properly
signed, and even then only set whitelisted variables, seems promising.
Very interesting. This can be more flexible for any future add-on.
>
>> In the UDP packet, I'm thinking to insert a grub command line. This is
very similar to pressing E when grub asks what to do at boot.
>
>
> I don't think it is the best choice to mimic user input. It is much safer
to select from among existing entries.
I agree about the safety but allowing this will complete the circle.
>
>>
>> I'm not sure of why you have wrote about kernel files. I never wrote
about sending files because this should be done by a PXE or bootp but this
is NOT my goal.
>>
>> Another very useful thing, should be that GRUB sends an encrypted UDP
packet with his menu configuration in order to do a reasonable choice from
a third party application.
>>
>>
>> Many thanks for your time.
>>
>> Daniele.
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
[-- Attachment #2: Type: text/html, Size: 5591 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2014-12-07 16:41 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-29 1:10 Remotely choose a menu entry Brugnara Daniele
2014-11-29 16:03 ` Andrei Borzenkov
2014-11-29 16:16 ` Brugnara Daniele
2014-12-01 8:19 ` Parmeshwr_Prasad
2014-12-01 10:37 ` Andrei Borzenkov
2014-12-01 10:43 ` Parmeshwr_Prasad
2014-12-01 11:29 ` Andrei Borzenkov
2014-12-01 11:30 ` Parmeshwr_Prasad
2014-12-01 23:13 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-12-02 6:22 ` Parmeshwr_Prasad
2014-12-02 16:22 ` Autopilot, a module for remotely doing things Brugnara Daniele
2014-12-03 7:42 ` Andrei Borzenkov
2014-12-03 8:18 ` Brugnara Daniele
2014-12-03 8:31 ` Andrei Borzenkov
2014-12-03 17:00 ` Brugnara Daniele
2014-12-03 18:03 ` Alan Perry
2014-12-03 20:03 ` Brugnara Daniele
2014-12-03 20:34 ` Brugnara Daniele
2014-12-04 6:26 ` Andrei Borzenkov
2014-12-04 3:41 ` Andrei Borzenkov
2014-12-07 16:41 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-12-01 12:03 Remotely choose a menu entry Brugnara Daniele
2014-12-01 16:43 ` Jonathan McCune
2014-12-01 18:59 ` Brugnara Daniele
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.