於 二，2012-12-25 於 10:24 +0800，Lingzhu Xiang 提到：
> On 12/24/2012 07:00 PM, joeyli wrote:
> > 於 五，2012-12-21 於 19:05 +0800，Lingzhu Xiang 提到：
> >> The following reproducer triggers certain bugs in efivarfs_file_write.
> >>
> >> #!/bin/bash
> >> p=/sys/firmware/efi/efivars
> >> mount -t efivarfs - $p
> >> cat $p/Lang-*>$p/test-12341234-1234-1234-1234-123412341234
> >> umount $p
> >> mount -t efivarfs - $p
> >> echo -en "\0\0\0\0">$p/test-12341234-1234-1234-1234-123412341234
> >
> > The problem is check EFI_VARIABLE_MASK in efivars.c that is not enough
> > for deny use 0x00000000 attributes.
> >
> > Per UEFI spec, runtime variable at least need has attributes
> > EFI_VARIABLE_BOOTSERVICE_ACCESS and EFI_VARIABLE_RUNTIME_ACCESS.
> > Otherwise UEFI BIOS will occur unexpected error.
> >
> > Please try the following patch.
>
> Thank you for your patch.
>
> Per UEFI spec, echo -en "\0\0\0\0" should be equivalent to deleting.
Per spec, the variable will be deleted when set DataSize to zero:
Unless the EFI_VARIABLE_APPEND_WRITE,
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS, or
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute is set, a
size of zero causes the variable to be deleted.
But, about the attributes description of SetVariable, it said:
Attributes Attributes bitmask to set for the variable. Refer to the
GetVariable() function description.
In description of GetVariable(), it reference to the definitions of
"Variable Attributes", it said:
Any attempts to access a variable that does not have the attribute set
for runtime access will yield the EFI_NOT_FOUND error.
So, if doesn't set any attribute, then will receive EFI_NOT_FOUND. That
also means we should not allow 0x00000000 in SetVariable(). I still
think we should reply -EINVAL to user space application when they do not
set any attributes.
> This is what efivarfs_unlink is doing but I wanted to avoid its
> underflowing when reproducing this.
>
> This still reproduces the bug and passes the check in your patch:
>
> echo -en "\x07\0\0\0" >$p/test-12341234-1234-1234-1234-123412341234
I can NOT reproduce issue by feeding "\x07\0\0\0" to variable on my
system, the test variable was been deleted normally.
My 2 testing environment:
+ qemu-kvm with OVMF-0.1+r13902-1.1.x86_64 on openSUSE
+ Intel DQ57TM board (Tunnel Mountain) with B.11 UEFI BIOS
Kernel version is:
+ latest commit is 54e37b8dbe on Linus kernel tree
with
my patch for check attributes need define bootservice and runtime
access
I can not reproduce on OVMF and Intel DQ57TM board. After I delete
variable, I also umount/mount filesystem a couple of times and
write/delete again, didn't reproduce issue.
Maybe you can try v3.8-rc1 kernel.
>
> > diff --git a/drivers/firmware/efivars.c b/drivers/firmware/efivars.c
> > index 7b1c374..7aeb4a5 100644
> > --- a/drivers/firmware/efivars.c
> > +++ b/drivers/firmware/efivars.c
> > @@ -706,6 +706,10 @@ static ssize_t efivarfs_file_write(struct file *file,
> > if (attributes& ~(EFI_VARIABLE_MASK))
> > return -EINVAL;
> >
> > + if (!((attributes& EFI_VARIABLE_BOOTSERVICE_ACCESS)&&
> > + (attributes& EFI_VARIABLE_RUNTIME_ACCESS)))
> > + return -EINVAL;
> > +
> > efivars = var->efivars;
>
> --
> Lingzhu Xiang
>
Thanks
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
