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: <20160208214210.GT1779@malice.jf.intel.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ