於 二，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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
