Skip to contentSkip to conversation

ipmi: Setting OS name as Linux in BMC

PATCH In review [email protected] 4 participants 8 messages Jun 28, 2012 – Jul 4, 2012 1 message not in the archive IPMI

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw

PATCH v2 1/1 ipmi: Setting OS name as Linux in BMC

functions that will send the Set System Info command and its corresponding handler

---
 drivers/char/ipmi/ipmi_msghandler.c |   73 +++++++++++++++++++++++++++++++++++
 include/linux/ipmi_msgdefs.h        |    1 +
 2 files changed, 74 insertions(+), 0 deletions(-)
drivers/char/ipmi/ipmi_msghandler.c +73 -0
index d0abb3a..b1a98b5 100644
@@ -2709,6 +2709,79 @@ get_guid(ipmi_smi_t intf)
 	intf->null_user_handler = NULL;
 }
 
+static int 
+send_set_os_name_cmd(ipmi_smi_t intf)
+{
+	unsigned char param_select;
+	unsigned char set_selector;
+	unsigned char string_encode;
+	unsigned char str_len;
+	unsigned char data[9];
+
+	struct kernel_ipmi_msg            msg;
+	struct ipmi_system_interface_addr si;
+
+	si.addr_type = IPMI_SYSTEM_INTERFACE_ADDR_TYPE;
+	si.channel = IPMI_BMC_CHANNEL;
+	si.lun = 0;
+	
+	param_select  = 4;	/* parameter number for volatile OS name */
+	set_selector  = 0;	/* set selector, block 0 */
+	string_encode = 0;	/* ASCII Encoding */
+	str_len = 5;		/* length of ASCII string - "Linux" */
+	
+	data[0] = param_select;
+	data[1] = set_selector;
+	data[2] = string_encode;
+	data[3] = str_len;
+	data[4] = 'L';
+	data[5] = 'i';
+	data[6] = 'n';
+	data[7] = 'u';
+	data[8] = 'x';
+
+	msg.netfn = IPMI_NETFN_APP_REQUEST;
+	msg.cmd = IPMI_SET_SYSTEM_INFO;
+	msg.data = data;
+	msg.data_len = 9;
+	return i_ipmi_request(NULL,
+			      intf,
+			      (struct ipmi_addr *) &si,
+			      0,
+			      &msg,
+			      intf,
+			      NULL,
+			      NULL,
+			      0,
+			      intf->channels[0].address,
+			      intf->channels[0].lun,
+			      -1, 0);
+}
+
+/*
+ * msg handler for Set_System_Info cmd - set OS name 
+ */
+static void
+set_os_name_handler(ipmi_smi_t intf, struct ipmi_recv_msg *msg)
+{
+	if ((msg->addr.addr_type != IPMI_SYSTEM_INTERFACE_ADDR_TYPE)
+	    || (msg->msg.netfn != IPMI_NETFN_APP_RESPONSE)
+	    || (msg->msg.cmd != IPMI_SET_SYSTEM_INFO))
+		/* Not for me */
+		return;
+
+	if (msg->msg.data[0] != 0) 
+		/* Error  setting OS name as Linux in BMC. */
+		printk(KERN_WARNING PFX 
+			"Failed to set OS name as Linux: 0x%X\n", msg->msg.data[0]);
+	else
+		printk(KERN_INFO PFX 
+			"OS Name successfully set as Linux\n");		
+
+	os_name_set = 1;
+	wake_up(&intf->waitq);
+}
+
 /*
  *   Set the Operating System Name as "Linux" in BMC 
  *   using "Set System Info" command.
include/linux/ipmi_msgdefs.h +1 -0
index df97e6e..b5ea664 100644
@@ -57,6 +57,7 @@
 #define IPMI_GET_BMC_GLOBAL_ENABLES_CMD	0x2f
 #define IPMI_READ_EVENT_MSG_BUFFER_CMD	0x35
 #define IPMI_GET_CHANNEL_INFO_CMD	0x42
+#define IPMI_SET_SYSTEM_INFO		0x58
 
 /* Bit for BMC global enables. */
 #define IPMI_BMC_RCV_MSG_INTR     0x01
Signature · 5 lines
1.7.1


Thanks,
G
#2 lore raw

drivers/char/ipmi/ipmi_msghandler.c get_guid(ipmi_smi_t intf) · line 2741

Quoted 10 lines · <[email protected]> writes:
drivers/char/ipmi/ipmi_msghandler.c +10 -0
+	
+	data[0] = param_select;
+	data[1] = set_selector;
+	data[2] = string_encode;
+	data[3] = str_len;
+	data[4] = 'L';
+	data[5] = 'i';
+	data[6] = 'n';
+	data[7] = 'u';
+	data[8] = 'x';

Not sure that's all that useful. I can just see BMC's making the ACPI mistake of trying to work around specific issues, by checking for Linux.

But since there are so many different Linux that will never work because "Linux" does not describe a fixed release or code base.

Probably dangerous.

-Andi

Signature · 1 line
[email protected] -- Speaking for myself only
#3 lore raw

Srinivas, what is your use case?

-corey

Quoted 23 lines · Andi Kleen

drivers/char/ipmi/ipmi_msghandler.c get_guid(ipmi_smi_t intf) · line 2741

Quoted 10 lines · <[email protected]> writes:
drivers/char/ipmi/ipmi_msghandler.c +10 -0
+	
+	data[0] = param_select;
+	data[1] = set_selector;
+	data[2] = string_encode;
+	data[3] = str_len;
+	data[4] = 'L';
+	data[5] = 'i';
+	data[6] = 'n';
+	data[7] = 'u';
+	data[8] = 'x';

Not sure that's all that useful. I can just see BMC's making the ACPI mistake of trying to work around specific issues, by checking for Linux.

But since there are so many different Linux that will never work because "Linux" does not describe a fixed release or code base.

Probably dangerous.

-Andi

#4 lore raw
In reply to Andi Kleen
Quoted 8 lines · Andi Kleen

Not sure that's all that useful. I can just see BMC's making the ACPI mistake of trying to work around specific issues, by checking for Linux.

But since there are so many different Linux that will never work because "Linux" does not describe a fixed release or code base.

Probably dangerous.

Agreed. Linux doesn't make interface guarantees to hardware, and where we've implied that we do it's ended up breaking things.

Signature · 1 line
Matthew Garrett | [email protected]
#5 lore raw
Quoted 4 lines · Matthew Garrett
Quoted 3 lines · Andi Kleen

Not sure that's all that useful. I can just see BMC's making the ACPI mistake of trying to work around specific issues, by checking for Linux.

I'm not sure I see that happening, but I suppose you never know.

Quoted 8 lines
Quoted 5 lines

But since there are so many different Linux that will never work because "Linux" does not describe a fixed release or code base.

Probably dangerous.

Agreed. Linux doesn't make interface guarantees to hardware, and where we've implied that we do it's ended up breaking things.

This is not really about making interface guarantees to hardware. This is more of a management discovery thing, so that system management software talking to the BMC can know what is running on the target. Something where management software can say "Hey, why is Linux running on that box? It's supposed to be BSD." or "That box has booted Linux but hasn't started its maintenance software". According to the spec, the information is supposed to be cleared if the system powers down or resets.

It seems to me that it's better to directly query what is running on the target to know what is running on it, but perhaps that's a security problem waiting to happen. And perhaps it's better to have a small program set this at startup, since this operation will currently fail on the majority of systems out there.

-corey

#6 lore raw
Quoted 5 lines · Corey Minyard

seems to me that it's better to directly query what is running on the
target to know what is running on it, but perhaps that's a security problem waiting to happen. And perhaps it's better to have a small program set this at startup, since this operation will currently fail on the majority of systems out there.

Hi All,
The intend of this patch was not to really workaround any issues, the aim was for the management software to use this data. I think Corey summed it up pretty well in his previous comment. Management software associated with BMC usually use this information to let the users know about the OS that is using the BMC. Generally there are 3rd party application software that goes and pretty much fills up the OS env information and the management software uses this. My intend was why don't we get this information loaded by the driver itself. If there are applications that wants to rewrite it, so be it..! Rather than just have a static entry such as 'Linux' I could probably write the version number and more(distro name etc.. )

Thoughts.. ?

I know there were some concerns with the security aspect, Can you please let me know what kind of security holes we could be looking at ?

Thanks,
G

#7 lore raw
Quoted 1 line

The intend of this patch was not to really workaround any issues, the aim was for the management software to use this data.

.. use it to do something "Linux" specific right?

I think Corey summed it up pretty well in his previous comment. Management software associated with BMC usually use this information to let the users know about the OS that is using the BMC. Generally there are 3rd party application software that goes and pretty much fills up the OS env information and the management software uses this. My intend was why don't we get this information loaded by the driver itself. If there are applications that wants to rewrite it, so be it..!

Quoted 3 lines

Rather than just have a static entry such as 'Linux' I could probably write the version number and more(distro name etc.. )

Thoughts.. ?

I still think "Linux" means nothing even to the management software. What should it do with that?

If you provide some way for a distro to fill in "foobar linux 1.2.3.4" maybe. But just Linux or even Linux x.y.z would be wrong because the same kernel version can behave very differently.

But it would be better to define specific feature flags for specific needs that actually mean something.

Quoted 1 line

I know there were some concerns with the security aspect, Can you please let me know what kind of security holes we could be looking at ?

I don't think there are any security problems. just forward/backward compatibility problems, as the ACPI experience shows.

-Andi

Signature · 1 line
[email protected] -- Speaking for myself only.
#8 lore raw
Quoted 6 lines · Andi Kleen
Quoted 3 lines

Rather than just have a static entry such as 'Linux' I could probably write the version number and more(distro name etc.. )

Thoughts.. ?

I still think "Linux" means nothing even to the management software. What should it do with that?

Quoted 6 lines

If you provide some way for a distro to fill in "foobar linux 1.2.3.4" maybe. But just Linux or even Linux x.y.z would be wrong because the same kernel version can behave very differently.

But it would be better to define specific feature flags for specific needs that actually mean something.

I think the conclusion I have come to is that this really belongs as a small program that runs at startup. That's not significantly different than having it done in the driver. I can help you write it, if you like.

I think Andi is right here. "Linux" may mean something to your management software. Some other management software may want "Linux x.y.z". Another may want "SuSE Enterprise Linux x.y". It's impossible to be general enough in the kernel.

Quoted 4 lines
Quoted 2 lines

I know there were some concerns with the security aspect, Can you please let me know what kind of security holes we could be looking at ?

I don't think there are any security problems. just forward/backward compatibility problems, as the ACPI experience shows.

I had mentioned possible security issues with having some daemon that identified the system directly over IP. I don't think there are any issues with IPMI, at least not any more than you already have with IPMI, and it's reasonably secure for what it does.

-corey