Re: General protection fault in efivarfs

[joeyli <jlee-IBi9RG/b67k@public.gmane.org>]

於 二，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