[Skiboot] [PATCH v1 0/5] New HBRT interfaces

[Daniel M Crowell]

So this "--enable-danger-mode" would be required upon initial invocation 
of opal-prd or as part of sending a command?

I'm just not seeing what adding this argument gets us.  If you really 
think that we need to hit people over the head with this information then 
we should change the command itself to something more frightening.  If 
we're worried about a user bricking their system, we need to restrict all 
access to pnor and vpd.  It is a lot easier to permanently make a system 
unbootable by messing around there then it is to call an obscure 
htmgt_pass_thru interface.

--
Dan Crowell
Senior Software Engineer - Power Systems Enablement Firmware
IBM Rochester: t/l 553-2987
dcrowell at us.ibm.com



From:   Jeremy Kerr <jk at ozlabs.org>
To:     Stewart Smith <stewart at linux.vnet.ibm.com>, Daniel M 
Crowell/Rochester/IBM at IBMUS
Cc:     Bill Schwartz/Austin/IBM at IBMUS, Christopher J 
Cain/Rochester/IBM at IBMUS, Neelesh Gupta <neelegup at linux.vnet.ibm.com>, 
skiboot at lists.ozlabs.org
Date:   08/13/2015 08:42 PM
Subject:        Re: [Skiboot] [PATCH v1 0/5] New HBRT interfaces



Hi Stewart,

> Sounds like an --enable-danger-mode would be the best bet.
>
> Along with printing out a giant warning.

Sounds good. Then (as Dan mentioned), we don't need separate builds to 
enable this.

> we were also discussing the idea of tainting the kernel if you run any
> of these, and maybe introducing similar idea into skiboot.

This taint wouldn't be a definite indication that someone has messed 
with these commands, as they could simply remove the (userspace) code 
that adds the taint.

[The kernel has no specific indication that we've invoked certain HBRT 
interfaces]

Cheers,


Jeremy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20150814/6bdf7c66/attachment-0001.html>