linux-kernel - Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a separate module

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]

Date:	Mon, 8 Feb 2016 13:42:10 -0800
From:	Darren Hart <dvhart@...radead.org>
To:	Michał Kępień <kernel@...pniu.pl>
Cc:	Pali Rohár <pali.rohar@...il.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Richard Purdie <rpurdie@...ys.net>,
	Jacek Anaszewski <j.anaszewski@...sung.com>,
	Alex Hung <alex.hung@...onical.com>,
	platform-driver-x86@...r.kernel.org, linux-leds@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/14] dell-laptop: extract SMBIOS-related code to a
 separate module

On Thu, Jan 21, 2016 at 02:39:21PM +0100, Michał Kępień wrote:
> > Another idea:
> > 
> > What about passing struct calling_interface_buffer from caller allocated
> > memory (either from stack or kernel alloc) to dell-smbios which will
> > copy it into own buffer under 4GB and then pass it to dcdbas?
> > 
> > This will avoid to use that get/release function and there will be only
> > one send_request.
> 
> Well, yes, these two functions could then be ripped out, but the callers
> would have to do the error checking on their own.  Of course that's not
> a bad thing per se, but it changes the currently used concept.
> 
> > But I will let decision for API to other people as I do not know what
> > the best API to use here...
> 
> In order to avoid delaying this any further, I'll post a v2 soon and
> hopefully it'll be good enough for your Acked-by.  If it turns out more
> people have misgivings about it, I'll adjust the code.
> 

It seems to me the question is primarily over whether or not the interface
protects a shared resource (a common buffer) or if that buffer should be
independent for every caller.

I favor minimal and incremental change and avoiding complexity where it is not
needed. I don't believe there is anything performance critical in any of these
paths, e.g. nothing requires a better response time than about 100ms and nothing
is likely to occur at a frequency above 10Hz or so.

Assuming the above is an accurate view, I don't see any reason to go beyond the
minimal change to the existing SMBIOS code to make it a usable API. If the need
arises, we can always make such optimizations and performance improvements
later. This is an internal API and we can change it whenever we need to so long
as we update the call sites.

Does anyone have a compelling reason to look for changes to the v2 submitted by
Michał?

-- 
Darren Hart
Intel Open Source Technology Center