linux-kernel - Re: [PATCH] Intel Management Engine Interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071211194751.GB21864@one.firstfloor.org>
Date:	Tue, 11 Dec 2007 20:47:51 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	David Miller <davem@...emloft.net>
Cc:	andi@...stfloor.org, nashif@...ux.intel.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Intel Management Engine Interface

On Tue, Dec 11, 2007 at 11:02:02AM -0800, David Miller wrote:
> From: Andi Kleen <andi@...stfloor.org>
> Date: Tue, 11 Dec 2007 19:53:17 +0100
> 
> > Ok but saving oops is such a useful facility that we'll probably
> > need to think about implementing SOAP in the kernel.
> 
> Ummm, no.
> 
> UDP is stateless, a stripped down copy of TCP we simply

UDP? Anyways it turns out TCP is not even needed.

> do not need.  We also do not need XML in the kernel either.

Even if it means you can get users to submit clear logged oopses out 
of many machines who hung silently before? 

Sure most of the XML infrastructure that tends to be used in 
user space is pure bloat. But if you don't want universal
interoperability and just for specific applications
you'll essentially just have a few hardcoded strings that
you'll write down some firmware interface and then a simple
parser to read the results. Again that wouldn't be a generic
XML parser, but just something tailored to the specific job.

I doubt it would be much worse code-wise than some of the more 
bizarre /proc ASCII interfaces.

> If they want to support things like this they should do it in the
> firmware of the management entity like every other sane server
> platform does these days.

They do -- the problem is that you need SOAP to talk the firmware.
After reboot the user space can get it out of the firmware again.

> The console and OOPS messages should go over an extremely resilient
> transport which is as simple as possible which usually means shared
> memory or I/O memory with some simple handshake or doorbell.  This

With soap it would be a slightly more complicated handshake 
and a few hard coded text strings around the actual information.
While that's not pretty if the result is worth it (and I think
general oops logging would be worth a lot of things) that's not too
bad.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/