linux-kernel - Re: [PATCH 2/4] power_supply: add eeprom dump file to olpc

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] [day] [month] [year] [list]

Date:	Wed, 30 Apr 2008 19:14:38 -0400
From:	Andres Salomon <dilinger@...ued.net>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	cbou@...l.ru, linux-kernel@...r.kernel.org, dwmw2@...radead.org
Subject: Re: [PATCH 2/4] power_supply: add eeprom dump file to
 olpc_battery's sysfs

On Wed, 30 Apr 2008 14:53:11 -0700
Andrew Morton <akpm@...ux-foundation.org> wrote:

> On Wed, 30 Apr 2008 16:30:08 -0400
> Andres Salomon <dilinger@...ued.net> wrote:
> 
> > 
> > This allows you to dump 0x60 bytes from the battery's EEPROM (starting
> > at address 0x20).  Note that it does an EC command for each byte, so
> > it's pretty slow.  OTOH, if you want to grab just a single byte from
> > somewhere in the EEPROM, you can do something like:
> > 
> > dd bs=1 count=1 skip=16 if=/sys/class/power_supply/olpc-battery/eeprom | od -x
> > 
> > Userspace battery collection/logging information needs this.
> > 
> > Signed-off-by: Andres Salomon <dilinger@...ian.org>
> > ---
> >  drivers/power/olpc_battery.c |   49 ++++++++++++++++++++++++++++++++++++++++++
> >  1 files changed, 49 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
> > index 9d9dd09..e5ecf27 100644
> > --- a/drivers/power/olpc_battery.c
> > +++ b/drivers/power/olpc_battery.c
> > @@ -283,6 +283,48 @@ static enum power_supply_property olpc_bat_props[] = {
> >  	POWER_SUPPLY_PROP_SERIAL_NUMBER,
> >  };
> >  
> > +/* EEPROM reading goes completely around the power_supply API, sadly */
> > +
> > +#define EEPROM_START	0x20
> > +#define EEPROM_END	0x80
> > +#define EEPROM_SIZE	(EEPROM_END - EEPROM_START)
> > +
> > +static ssize_t olpc_bat_eeprom_read(struct kobject *kobj,
> > +		struct bin_attribute *attr, char *buf, loff_t off, size_t count)
> > +{
> > +	uint8_t ec_byte;
> > +	int ret, end;
> > +
> > +	if (off >= EEPROM_SIZE)
> > +		return 0;
> 
> loff_t is signed.
> 
> Happily, the VFS prevents negative loff_t's from being passed into read()
> handlers.
> 
> > +	if (off + count > EEPROM_SIZE)
> > +		count = EEPROM_SIZE - off;
> 
> But the vfs doesn't check for (offset+len) going negative (I think?)
> 
> However you got lucky (or smart ;)) - size_t is unsigned so the comparison
> will dtrt.
> 
> Plus the first `if' will prevent us getting here with huge-nearly-negative
> `off'.
> 
> This stuff is harder than it should be :(
> 

Agreed.  I actually tested it a bunch with of different i/o back in Feb
in an attempt to break it.  I think it looks horrid; if there's a better
interface for this, I'd be more than happy to switch.
--
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/