On 06/02/2013 04:06 AM, Matthew Garrett wrote:
This patch reworks the UEFI anti-bricking code, including an effective
reversion of cc5a080c and 31ff2f20. It turns out that calling
QueryVariableInfo() from boot services results in some firmware
implementations jumping to physical addresses even af
於 一，2013-06-03 於 16:31 +，Matthew Garrett 提到：
> On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
>
> > Oliver raised a question for if power fails between that succesful
> > attempt and the deletion?
>
> It's a pretty tiny window, but sure. Making sure we delete it seems
> sensible. In that ca
On Mon, Jun 03, 2013 at 02:19:05PM -0700, James Bottomley wrote:
> On Mon, 2013-06-03 at 19:11 +0100, Matthew Garrett wrote:
> > No. I'm saying that calling it with the 1:1 map is something very
> > different to the behaviour of Windows, and I'm saying that doing so is
> > known to cause variable
On Mon, 2013-06-03 at 19:11 +0100, Matthew Garrett wrote:
> > > The problem there is that you're saying "In theory". We know that
> > > Windows doesn't behave this way, so we have no legitimate expectation
> > > that it'll work. We know that it doesn't on some Apple hardware.
> >
> > Fine, you s
On Mon, Jun 03, 2013 at 11:05:03AM -0700, James Bottomley wrote:
> On Mon, 2013-06-03 at 17:42 +0100, Matthew Garrett wrote:
> > Why do you persist in this belief that all system vendors are going to
> > have run a shell, let alone any kind of test suite? That runs counter to
> > everything we've
On Mon, 2013-06-03 at 17:42 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 09:35:07AM -0700, James Bottomley wrote:
> > On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote:
> > > That seems optimistic. Windows never calls QueryVariableInfo() during
> > > boot services, so what makes
> Who wants to pick this one up? Tony?
Sure - I'll take it.
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jun 03, 2013 at 09:35:07AM -0700, James Bottomley wrote:
> On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote:
> > That seems optimistic. Windows never calls QueryVariableInfo() during
> > boot services, so what makes you think doing so has ever been tested?
>
> It's used by the UEF
On Mon, 2013-06-03 at 17:24 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 09:18:06AM -0700, James Bottomley wrote:
>
> > I don't entirely buy that. All EFI programs run with the physical
> > address map, therefore every API an EFI program uses is also tested, at
> > boot time only, obvi
On Tue, 2013-06-04 at 00:13 +0800, joeyli wrote:
> Oliver raised a question for if power fails between that succesful
> attempt and the deletion?
It's a pretty tiny window, but sure. Making sure we delete it seems
sensible. In that case we should make the GUID a #define rather than
write it out t
於 六，2013-06-01 於 16:06 -0400，Matthew Garrett 提到：
> + unsigned long dummy_size = remaining_size + 1024;
> + void *dummy = kmalloc(dummy_size, GFP_ATOMIC);
> + efi_char16_t efi_name[6] = { 'D', 'U', 'M', 'M', 'Y', 0 };
> + efi_guid_t guid = EFI_
On Mon, 2013-06-03 at 16:21 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 07:38:02AM -0700, James Bottomley wrote:
> > On Mon, 2013-06-03 at 15:30 +0100, Matthew Garrett wrote:
> > > Windows calls SetVirtualAddressMap(), so the only way these systems have
> > > been tested is with SetVir
On Mon, Jun 03, 2013 at 09:18:06AM -0700, James Bottomley wrote:
> I don't entirely buy that. All EFI programs run with the physical
> address map, therefore every API an EFI program uses is also tested, at
> boot time only, obviously.
That seems optimistic. Windows never calls QueryVariableInfo
On Mon, Jun 03, 2013 at 07:38:02AM -0700, James Bottomley wrote:
> On Mon, 2013-06-03 at 15:30 +0100, Matthew Garrett wrote:
> > Windows calls SetVirtualAddressMap(), so the only way these systems have
> > been tested is with SetVirtualAddressMap().
>
> I know, but that's not what I said.
>
> If
On Mon, 2013-06-03 at 13:17 +0100, Matt Fleming wrote:
> Do we really want to drop this hunk? The point of this code was to
> inform firmware vendors that their implementation is returning funky
> results, and that they should look into why it's doing that.
We're not doing anything with that info
On Mon, 03 Jun, at 03:32:52PM, Matthew Garrett wrote:
> We can only pass one set of addresses to SetVirtualAddressMap(), but it
> doesn't seem like there's any intrinsic reason we can't the runtime
> regions mapped to multiple virtual addresses.
Indeed. That's the approach I took with my 1:1 ser
On Mon, 2013-06-03 at 15:30 +0100, Matthew Garrett wrote:
> On Mon, Jun 03, 2013 at 07:27:22AM -0700, James Bottomley wrote:
>
> > That's correct. I think not calling SetVirtualAddressMap() and just
> > using a 1:1 mapping is far safer (having looked at what tianocore does
> > for SetVirtualAddre
On Mon, Jun 03, 2013 at 10:11:48AM +0200, Borislav Petkov wrote:
> On Sun, Jun 02, 2013 at 11:56:20PM +0100, Matthew Garrett wrote:
> > I've just run Windows 8 under a hacked up copy of OVMF that dumps
> > the data passed to SetVirtualAddressMap. It seems that Windows *is*
> > mapping the runtime s
On Mon, Jun 03, 2013 at 07:27:22AM -0700, James Bottomley wrote:
> That's correct. I think not calling SetVirtualAddressMap() and just
> using a 1:1 mapping is far safer (having looked at what tianocore does
> for SetVirtualAddressMap()). The chances are that all the UEFI bioses
> are only teste
On Mon, 2013-06-03 at 10:11 +0200, Borislav Petkov wrote:
> On Sun, Jun 02, 2013 at 11:56:20PM +0100, Matthew Garrett wrote:
> > I've just run Windows 8 under a hacked up copy of OVMF that dumps
> > the data passed to SetVirtualAddressMap. It seems that Windows *is*
> > mapping the runtime services
On 01/06/13 21:06, Matthew Garrett wrote:
> This patch reworks the UEFI anti-bricking code, including an effective
> reversion of cc5a080c and 31ff2f20. It turns out that calling
> QueryVariableInfo() from boot services results in some firmware
> implementations jumping to physical addresses even a
On Sat, 01 Jun, at 11:40:02AM, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer
> ---
>
> diff -u -p a/drivers/firmware/efi/efi-pstore.c
> b/drivers/firmware/efi/efi-pstore.c
> --- a/drivers/firmware/efi/efi-pstore.c
> +++ b/drivers/firmware/efi/efi-pstore.c
> @@ -79,10 +79,9 @@ static int e
On Sun, Jun 02, 2013 at 11:56:20PM +0100, Matthew Garrett wrote:
> I've just run Windows 8 under a hacked up copy of OVMF that dumps
> the data passed to SetVirtualAddressMap. It seems that Windows *is*
> mapping the runtime services to higher addresses - so presumably the
> 1:1 mapping is in addit
23 matches
Mail list logo
