於 四，2012-09-13 於 21:41 -0700，H. Peter Anvin 提到：
> On 09/13/2012 08:45 PM, joeyli wrote:
> > Hi Peter,
> >
> > 於 四，2012-09-13 於 09:52 -0400，Peter Jones 提到：
> >> On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
> >>
> >>> Do we have plan to create a new kobject add to /sys/firmware/efi for
> >>> prov
於 二，2012-09-11 於 15:23 +0800，lee joey 提到：
> From: Matthew Garrett
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI
> specification,
> but was removed before any full releases. Since variables can now be
> larger
On 09/13/2012 08:45 PM, joeyli wrote:
Hi Peter,
於 四，2012-09-13 於 09:52 -0400，Peter Jones 提到：
On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
Do we have plan to create a new kobject add to /sys/firmware/efi for
provide a fixed mount point to efivars fs?
e.g. /sys/firmware/efi/efivars
Or we j
Hi Peter,
於 四，2012-09-13 於 09:52 -0400，Peter Jones 提到：
> On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
>
> > Do we have plan to create a new kobject add to /sys/firmware/efi for
> > provide a fixed mount point to efivars fs?
> > e.g. /sys/firmware/efi/efivars
> >
> > Or we just direct reuse
On Thu, 2012-09-13 at 16:10 +0800, joeyli wrote:
> Do we have plan to create a new kobject add to /sys/firmware/efi for
> provide a fixed mount point to efivars fs?
> e.g. /sys/firmware/efi/efivars
>
> Or we just direct reuse current /sys/firmeware/efi/vars? But, that means
> we need think for th
於 二，2012-09-11 於 15:23 +0800，lee joey 提到：
> From: Matthew Garrett
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI
> specification,
> but was removed before any full releases. Since variables can now be
> larger
On Thu, 2012-09-06 at 13:40 +0800, Jeremy Kerr wrote:
> From: Matthew Garrett
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI
> specification,
> but was removed before any full releases. Since variables can now
On Thu, 2012-09-06 at 22:37 +0800, Jeremy Kerr wrote:
> That's correct, but we can't use unlink to delete a secure variable, we
> need to do a write instead, in order to provide the authentication
> descriptor.
Ah, duh. Thanks for clearing that up.
--
To unsubscribe from this list: send the lin
Hi Matt,
I think this is the problematic chunk of code,
static int efivars_unlink(struct inode *dir, struct dentry *dentry)
{
struct efivar_entry *var = dentry->d_inode->i_private;
struct efivars *efivars = var->efivars;
efi_status_t status;
spin_lock(&efiva
(Cc'ing Peter Jones who wrote a auth deletion patch for efivars)
On Thu, 2012-09-06 at 22:23 +0800, Jeremy Kerr wrote:
> Hi Matt,
>
> > Am I correct in thinking that this filesystem doesn't handle deletion of
> > authenticated variables?
>
> Unless I'm missing something, this should work fine; w
Hi Matt,
Am I correct in thinking that this filesystem doesn't handle deletion of
authenticated variables?
Unless I'm missing something, this should work fine; we just pass the
EFI_VARIABLE_AUTHENTICATION_2 descriptor (with the usual attribute
header), but no data following the descriptor.
On Thu, 2012-09-06 at 13:40 +0800, Jeremy Kerr wrote:
> From: Matthew Garrett
>
> The existing EFI variables code only supports variables of up to 1024
> bytes. This limitation existed in version 0.99 of the EFI specification,
> but was removed before any full releases. Since variables can now be
From: Matthew Garrett
The existing EFI variables code only supports variables of up to 1024
bytes. This limitation existed in version 0.99 of the EFI specification,
but was removed before any full releases. Since variables can now be
larger than a single page, sysfs isn't the best interface for t
13 matches
Mail list logo
