linux-kernel - RE: [PATCH v2 3/3] efi: Capsule update with user helper 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: <F54AEECA5E2B9541821D670476DAE19C2B851058@PGSMSX102.gar.corp.intel.com>
Date:	Mon, 10 Nov 2014 08:31:56 +0000
From:	"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Sam Protsenko <semen.protsenko@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	"Fleming, Matt" <matt.fleming@...el.com>,
	"Ong, Boon Leong" <boon.leong.ong@...el.com>,
	Ming Lei <ming.lei@...onical.com>,
	"linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>
Subject: RE: [PATCH v2 3/3] efi: Capsule update with user helper interface

> -----Original Message-----
> From: Andy Lutomirski [mailto:luto@...capital.net]
> > #!/bin/sh
> >
> > old=$(cat
> > /sys/devices/platform/efi_capsule_user_helper/capsule_loaded)
> >
> > for arg in "$@"
> > do
> >         if [ -f $arg ]
> >         then
> >                 echo 1 > /sys/class/firmware/efi-capsule-file/loading
> >                 cat $arg > /sys/class/firmware/efi-capsule-file/data
> >                 echo 0 > /sys/class/firmware/efi-capsule-file/loading
> 
> I think you have a race.  Try putting msleep(1000) after the
> request_firmware_nowait call, and I bet this will fail on the second try.

Sorry for the late response. I don't really catch the race condition that
you are referring? Are you trying to tell that the user script could run faster
before the previous callback function actually end? Will such scenario happen?
In the callback function, after the request_firmware_nowait(), I don't have
any codes will delay the callback function to end. Besides, there is a mutex_lock
protecting the request_firmware_nowait() calling. Won't that take care of the
issue?

> 
> >
> >                 oldtime=$(date +%S)
> >                 oldtime=$(((time + 2) % 60))
> >                 until [ -f /sys/class/firmware/efi-capsule-file/loading ]
> >                 do
> >                         newtime=$(date +%S)
> >                         if [ $newtime -eq $oldtime ]
> >                         then
> >                                 break
> >                         fi
> >                 done
> >
> >                 old=$((old + 1))
> >                 new=$(cat
> > /sys/devices/platform/efi_capsule_user_helper/capsule_loaded)
> 
> I think that firmware_class doesn't call the callback until after loading is closed
> for the second time.  If so, then this is racy.  Try inserting msleep(1000) at the
> beginning of your callback and uploading a capsule that should load
> successfully -- this will report failure, but a future upload may get very
> confused. Also, what does the firmware class do when simultaneous
> uploads of the same file with different contents are in flight?  Is that possible?

Sorry again, I can't really catch you on this race condition statement. Are you
trying to tell if user is doing this:

echo 1 > /sys/class/firmware/efi-capsule-file/loading
cat capsule1 > /sys/class/firmware/efi-capsule-file/data
cat capsule2 > /sys/class/firmware/efi-capsule-file/data
echo 0 > /sys/class/firmware/efi-capsule-file/loading

If so, capsule2 will be the one we will obtain in the callback function.


Regards,
Wilson