Syslinux - Apr 2019 - RFC: Feature: MENU HIDDEN behaviour on ANY key

Hello,

Here's a small enhancement feature for menu.c32. Looking for feedback before
starting any coding (not sure when I'll have time for implementation)

Regards,
Dany St-Amant


*Problem statement*

When MENU HIDDEN is used on an headless server, any noise on the serial console
can interrupt the boot; it would be preferable if there only specific keys were
allowed to interrupt, reducing the probability of unwanted interruption. Even
with TOTALTIMEOUT present, there's a delay present as TOTALTIMEOUT has to be
large enough to make it useable during intentional boot interruption.

*Basic behaviour change*

Provide a way to assign "reveal menu" to specific key(s)
Provide a default behaviour for unassigned keys (other than current "reveal
menu")

*Possible user interface change*

MENU HIDDENMENUKEY key[,key]
MENU HIDDDENKEY key[,key] [command...]
Add ANY as an acceptable value for key
Make command optional, defaulting to boot default.

*Behaviour*

If pressed key is defined by HIDDENKEY, that action is always taken.
no HIDDENMENUKEY, no HIDDENKEY ANY: all keys bring the menu (current behaviour)
HIDDENMENUKEY ANY: all keys bring the menu (current behaviour)
HIDDENMENUKEY Esc, HIDDENKEY ANY (without commands): Esc brings the menu, all
keys autoboot
HIDDENMENUKEY Esc, no HIDDENKEY ANY: Esc brings the menu, all keys trigger
nothing.

*Exclusion*

No similar support for boot prompt.
No code/behaviour analysis made for cmenu.c32

*Affected code* (outside config parsing)

menumain.c:do_hidden_menu()
Extra comparison when handling mygetkey(),ignoring unbound key if ANY not
assigned (or defaulted). Return NULL, if hide_key[key] matches HIDDENMENUKEY. A
few extra globals likely required to track/reference pseudo-commands
"reveal menu" and "boot default" inside hide_key[] table.
Need to use/steal an unused entry of hide_key[] as the ANY key.

*Rejected/discarded interface option*

MENU HIDDENSECUREKEY key[,key] [STRICT]
MENU HIDDENDEFAULTKEY 0|1
MENU HIDDENANYKEY MENU|IGNORE|BOOT
MENU HIDDENKEY ANY|key[,key] MENU|IGNORE|BOOT|command...

Last one is rejected to avoid collision with exiting configuration which might
be using label matching the keywords.

I too think it would be nice to define the keys to show the menu if desired!

Thanks,
Dave


On 4/10/19, Dany St-Amant via Syslinux <syslinux at syslinux.org>
wrote:
> Hello,
>
> Here's a small enhancement feature for menu.c32. Looking for feedback
before
> starting any coding (not sure when I'll have time for implementation)
>
> Regards,
> Dany St-Amant
>
>
> *Problem statement*
>
> When MENU HIDDEN is used on an headless server, any noise on the serial
> console can interrupt the boot; it would be preferable if there only
> specific keys were allowed to interrupt, reducing the probability of
> unwanted interruption. Even with TOTALTIMEOUT present, there's a delay
> present as TOTALTIMEOUT has to be large enough to make it useable during
> intentional boot interruption.
>
> *Basic behaviour change*
>
> Provide a way to assign "reveal menu" to specific key(s)
> Provide a default behaviour for unassigned keys (other than current
"reveal
> menu")
>
> *Possible user interface change*
>
> MENU HIDDENMENUKEY key[,key]
> MENU HIDDDENKEY key[,key] [command...]
> Add ANY as an acceptable value for key
> Make command optional, defaulting to boot default.
>
> *Behaviour*
>
> If pressed key is defined by HIDDENKEY, that action is always taken.
> no HIDDENMENUKEY, no HIDDENKEY ANY: all keys bring the menu (current
> behaviour)
> HIDDENMENUKEY ANY: all keys bring the menu (current behaviour)
> HIDDENMENUKEY Esc, HIDDENKEY ANY (without commands): Esc brings the menu,
> all keys autoboot
> HIDDENMENUKEY Esc, no HIDDENKEY ANY: Esc brings the menu, all keys trigger
> nothing.
>
> *Exclusion*
>
> No similar support for boot prompt.
> No code/behaviour analysis made for cmenu.c32
>
> *Affected code* (outside config parsing)
>
> menumain.c:do_hidden_menu()
> Extra comparison when handling mygetkey(),ignoring unbound key if ANY not
> assigned (or defaulted). Return NULL, if hide_key[key] matches
> HIDDENMENUKEY. A few extra globals likely required to track/reference
> pseudo-commands "reveal menu" and "boot default" inside
hide_key[] table.
> Need to use/steal an unused entry of hide_key[] as the ANY key.
>
> *Rejected/discarded interface option*
>
> MENU HIDDENSECUREKEY key[,key] [STRICT]
> MENU HIDDENDEFAULTKEY 0|1
> MENU HIDDENANYKEY MENU|IGNORE|BOOT
> MENU HIDDENKEY ANY|key[,key] MENU|IGNORE|BOOT|command...
>
> Last one is rejected to avoid collision with exiting configuration which
> might be using label matching the keywords.
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at syslinux.org
> Unsubscribe or set options at:
> https://lists.syslinux.org/syslinux
>

> Hello,
> 
> Here's a small enhancement feature for menu.c32. Looking for feedback
before
> starting any coding (not sure when I'll have time for implementation)
> 
> Regards,
> Dany St-Amant
> 
> 
> *Problem statement*
> 
> When MENU HIDDEN is used on an headless server, any noise on the serial
> console can interrupt the boot; it would be preferable if there only
specific
> keys were allowed to interrupt, reducing the probability of unwanted
> interruption. Even with TOTALTIMEOUT present, there's a delay present
as
> TOTALTIMEOUT has to be large enough to make it useable during intentional
boot
> interruption.
 
 
Sounds like 'MENU SHIFTKEY' would be useful for your case.

> 
> *Basic behaviour change*
> 
> Provide a way to assign "reveal menu" to specific key(s)
 
 
One possible alternative would be to separate the cfg, or at least to not 
default to menu.c32. The initial cfg would use 'PROMPT 1' and
'TIMEOUT', and
the 'DEFAULT' directive would point to the default LABEL, instead of
triggering
menu.c32. The 'UI' directive would not be used in this initial cfg file
either,
of course. Then, a certain label would trigger the menu, at user's choice.
That
LABEL could be one "m" character. Using several 'SAY'
directives can work as
on-screen help "menu" for simple LABELs (no need to use fancy menus),
and
DISPLAY files can even send an output result to the serial console different 
than to a normal screen (but, please note that DISPLAY files are not always 
working correctly for UEFI). So, here we already have several potential 
alternatives.

I would also suggest reading
 http://www.syslinux.org/wiki/index.php/Directives/special_keys 

Independently of such potential alternative(s), the 'MENU SHIFTKEY'
directive
(explained in the "MENU" wiki page and also mentioned in the
"special keys"
wiki page) could be also combined with other directives, or it can be used 
without the 'MENU HIDDEN' directive.

> Provide a default behaviour for unassigned keys (other than current
"reveal
> menu")
 
 
For a workaround for ANY and/or unassigned keys, you could have multiple
'MENU
HIDDEN' directives, each with a list of multiple keys.

> *Possible user interface change*
> 
> MENU HIDDENMENUKEY key[,key]
> MENU HIDDDENKEY key[,key] [command...]
> Add ANY as an acceptable value for key
> Make command optional, defaulting to boot default.
> 
> *Behaviour*
> 
> If pressed key is defined by HIDDENKEY, that action is always taken.
> no HIDDENMENUKEY, no HIDDENKEY ANY: all keys bring the menu (current
> behaviour)
> HIDDENMENUKEY ANY: all keys bring the menu (current behaviour)
> HIDDENMENUKEY Esc, HIDDENKEY ANY (without commands): Esc brings the menu,
all
> keys autoboot
> HIDDENMENUKEY Esc, no HIDDENKEY ANY: Esc brings the menu, all keys trigger
> nothing.
> 
> *Exclusion*
> 
> No similar support for boot prompt.
> No code/behaviour analysis made for cmenu.c32
> 
> *Affected code* (outside config parsing)
> 
> menumain.c:do_hidden_menu()
> Extra comparison when handling mygetkey(),ignoring unbound key if ANY not
> assigned (or defaulted). Return NULL, if hide_key[key] matches
HIDDENMENUKEY.
> A few extra globals likely required to track/reference pseudo-commands
"reveal
> menu" and "boot default" inside hide_key[] table. Need to
use/steal an unused
> entry of hide_key[] as the ANY key.
> 
> *Rejected/discarded interface option*
> 
> MENU HIDDENSECUREKEY key[,key] [STRICT]
> MENU HIDDENDEFAULTKEY 0|1
> MENU HIDDENANYKEY MENU|IGNORE|BOOT
> MENU HIDDENKEY ANY|key[,key] MENU|IGNORE|BOOT|command...
> 
> Last one is rejected to avoid collision with exiting configuration which
might
> be using label matching the keywords.
 
 
Regarding the default command (i.e. when the command is not explicitly written 
at the end of the directive), I think the default behavior should (continue to) 
be to do nothing, as if the directive was not there. Such behavior is 
consistent with other directives too. Have you tested what happens as it is 
right now? FWIW, I disagree with breaking the current default behavior.

If the typical / normal / frequent use is with no menu, then isn't it
simpler
to have 'COM32 menu.c32' under a LABEL, or even as multiple equivalent
labels?

FWIW, I don't mind the introduction of new directives (I have my own
proposals
too), but changing the default behavior of current directives is not something 
I'm happy about; just my personal opinion.

Considering the extremely low pace of development, and the fact that too many 
patches and suggestions have been ignored during the last few years, perhaps 
evaluating some already-available alternatives (such as those mentioned above) 
might be more effective.

Regards,
Ady.

> Le 11 avr. 2019 ? 14:48, Ady Ady via Syslinux <syslinux at
syslinux.org> a ?crit :
> 
> 
>> Hello,
>> 
>> Here's a small enhancement feature for menu.c32. Looking for
feedback before
>> starting any coding (not sure when I'll have time for
implementation)
>> 
>> Regards,
>> Dany St-Amant
>> 
>> 
>> *Problem statement*
>> 
>> When MENU HIDDEN is used on an headless server, any noise on the serial
>> console can interrupt the boot; it would be preferable if there only
specific
>> keys were allowed to interrupt, reducing the probability of unwanted
>> interruption. Even with TOTALTIMEOUT present, there's a delay
present as
>> TOTALTIMEOUT has to be large enough to make it useable during
intentional boot
>> interruption.
> 
> 
> Sounds like 'MENU SHIFTKEY' would be useful for your case.
I have to admit that I did not tried MENU SHIFTKEY. I simply assumed that this
option was not going to work over serial connection. As these keys are not
supposed to send keystroke over serial.
>> *Basic behaviour change*
>> 
>> Provide a way to assign "reveal menu" to specific key(s)
> 
> 
> One possible alternative would be to separate the cfg, or at least to not 
> default to menu.c32. The initial cfg would use 'PROMPT 1' and
'TIMEOUT', and
> the 'DEFAULT' directive would point to the default LABEL, instead
of triggering
> menu.c32. The 'UI' directive would not be used in this initial cfg
file either,
> of course. Then, a certain label would trigger the menu, at user's
choice. That
> LABEL could be one "m" character. Using several 'SAY'
directives can work as
> on-screen help "menu" for simple LABELs (no need to use fancy
menus), and
> DISPLAY files can even send an output result to the serial console
different
> than to a normal screen (but, please note that DISPLAY files are not always
> working correctly for UEFI). So, here we already have several potential 
> alternatives.
My current configuration was making use of PROMPT 1, but for security reason
some options need to be move behind a password which currently can only be
achieved via menu.c32. Using a double config files setup might help, but this is
just working around the issue and not fixing it. Note that a configuration with
PROMPT 1 is also susceptible  to serial console noise. With your suggestion the
first "stage" would need a really small TOTALTIMEOUT to hide the
issue. A short and quick to type label for second stage invocation could work.
> I would also suggest reading
> http://www.syslinux.org/wiki/index.php/Directives/special_keys 
> 
> Independently of such potential alternative(s), the 'MENU SHIFTKEY'
directive
> (explained in the "MENU" wiki page and also mentioned in the
"special keys"
> wiki page) could be also combined with other directives, or it can be used 
> without the 'MENU HIDDEN' directive.
> 
> 
>> Provide a default behaviour for unassigned keys (other than current
"reveal
>> menu")
> 
> 
> For a workaround for ANY and/or unassigned keys, you could have multiple
'MENU
> HIDDEN' directives, each with a list of multiple keys.
Based on hide_key[] definitions one would need to list 0x12a entries, some of
which likely not having a worldly description to used by MENU HIDDENKEY.
>> *Possible user interface change*
>> 
>> MENU HIDDENMENUKEY key[,key]
>> MENU HIDDDENKEY key[,key] [command...]
>> Add ANY as an acceptable value for key
>> Make command optional, defaulting to boot default.
>> 
>> *Behaviour*
>> 
>> If pressed key is defined by HIDDENKEY, that action is always taken.
>> no HIDDENMENUKEY, no HIDDENKEY ANY: all keys bring the menu (current
>> behaviour)
>> HIDDENMENUKEY ANY: all keys bring the menu (current behaviour)
>> HIDDENMENUKEY Esc, HIDDENKEY ANY (without commands): Esc brings the
menu, all
>> keys autoboot
>> HIDDENMENUKEY Esc, no HIDDENKEY ANY: Esc brings the menu, all keys
trigger
>> nothing.
>> 
>> *Exclusion*
>> 
>> No similar support for boot prompt.
>> No code/behaviour analysis made for cmenu.c32
>> 
>> *Affected code* (outside config parsing)
>> 
>> menumain.c:do_hidden_menu()
>> Extra comparison when handling mygetkey(),ignoring unbound key if ANY
not
>> assigned (or defaulted). Return NULL, if hide_key[key] matches
HIDDENMENUKEY.
>> A few extra globals likely required to track/reference pseudo-commands
"reveal
>> menu" and "boot default" inside hide_key[] table. Need
to use/steal an unused
>> entry of hide_key[] as the ANY key.
>> 
>> *Rejected/discarded interface option*
>> 
>> MENU HIDDENSECUREKEY key[,key] [STRICT]
>> MENU HIDDENDEFAULTKEY 0|1
>> MENU HIDDENANYKEY MENU|IGNORE|BOOT
>> MENU HIDDENKEY ANY|key[,key] MENU|IGNORE|BOOT|command...
>> 
>> Last one is rejected to avoid collision with exiting configuration
which might
>> be using label matching the keywords.
> 
> 
> Regarding the default command (i.e. when the command is not explicitly
written
> at the end of the directive), I think the default behavior should (continue
to)
> be to do nothing, as if the directive was not there. Such behavior is 
> consistent with other directives too. Have you tested what happens as it is
> right now? FWIW, I disagree with breaking the current default behavior.
Sorry, I have not done my homework here. My suggested behaviour was based on the
definition of MENU HIDDENKEY on the wiki which doesn't mark command... as
optional. The current behaviour for HIDDENKEY without a command causes an error
when the key is hit: "Loading ... failed:" (as the code try to load
file "" from current location). This failure causes menu.c32 to be
restarted (the timeout get restarted) without reloading any files. Note that
similar behaviour also occurs if a kernel line is missing the kernel name. From
the boot prompt, using such label lead to an odd behaviour.
> If the typical / normal / frequent use is with no menu, then isn't it
simpler
> to have 'COM32 menu.c32' under a LABEL, or even as multiple
equivalent labels?
> 
> FWIW, I don't mind the introduction of new directives (I have my own
proposals
> too), but changing the default behavior of current directives is not
something
> I'm happy about; just my personal opinion.
Right, changing default behaviour is bad. But should the behaviour of currently
invalid syntax be kept?
> Considering the extremely low pace of development, and the fact that too
many
> patches and suggestions have been ignored during the last few years,
perhaps
> evaluating some already-available alternatives (such as those mentioned
above)
> might be more effective.
> 
> Regards,
> Ady.

Thanks for the suggestions,
Dany