Re: [Xen-devel] [PATCH] xen: remove XEN_PRIVILEGED_GUEST

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 24.02.2014 19:39, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 18, 2014 at 11:14:27AM +0100, Paul Bolle wrote:
>> On Mon, 2014-02-17 at 09:43 -0500, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Feb 17, 2014 at 02:03:17PM +0100, Paul Bolle wrote:
 On Mon, 2014-02-17 at 07:23 -0500, Konrad Rzeszutek Wilk wrote:
> On Feb 16, 2014 3:07 PM, Paul Bolle  wrote:
> Please look in the grub git tree. They have fixed their code to not do
> this anymore. This should be reflected in the patch description.

 Thanks, I didn't know that. That turned out to be grub commit
 ec824e0f2a399ce2ab3a2e3353d372a236595059 ("Implement grub_file tool and
 use it to implement generating of config"), see
 http://git.savannah.gnu.org/cgit/grub.git/commit/util/grub.d/20_linux_xen.in?id=ec824e0f2a399ce2ab3a2e3353d372a236595059
>>
>> And that commit was reverted a week later in grub commit
>> faf4a65e1e1ce1d822d251c1e4b53d96ec7faec5 ("Revert grub-file usage in
>> grub-mkconfig."), see
>> http://git.savannah.gnu.org/cgit/grub.git/commit/util/grub.d/20_linux_xen.in?id=faf4a65e1e1ce1d822d251c1e4b53d96ec7faec5
>>  .
>>
>> That commit has no explanation (other than its one line summary). So
>> we're left guessing why this was done. Luckily, it doesn't matter here,
>> because the test for CONFIG_XEN_PRIVILEGED_GUEST is superfluous.
> 
> How about we ask Vladimir?
> 
> Vladimir - could you shed some light on it? Thanks!
> 
CONFIG_XEN_PRIVILEGED_GUEST is not present on Linux even though it
should be. The test was removed to accomodate this.
The usage of grub-file was removed because it wasn't release-ready.
>>
>> Anyhow, I hope to submit a second version of this patch later this day.
>>
>>
>> Paul Bolle
>>
>>
>> ___
>> Xen-devel mailing list
>> xen-de...@lists.xen.org
>> http://lists.xen.org/xen-devel
> 




signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

>>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>> I added such a tag in documentation and wrote a patch for it (attached).
>> Awaiting for someone to test it to commit
> 
> Great! I think from Xen perspective we first need to have Xen be able
> to understand multiboot2 - that is something Daniel had been working on.
> I will let Daniel talk more about it.
> 
> Seth, would you have any time to test the patch against Solaris to
> make sure it works?
> 
I've committed that patch. BTW do you want protected mode or long mode
entry point for x86_64 variant? Currently it's protected mode but I
planned to add long mode possibility but it wasn't a priority.




signature.asc
Description: OpenPGP digital signature

Re: Is: Wrap-up Was: Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 30.10.2013 12:19, Daniel Kiper wrote:
> Hi,
> multiboot2 protocol requires some more changes. However, about 80% of code
> is ready. In this case Xen and modules are loaded by GRUB2 itself. It means
> that all images could be placed on any filesystem recognized by GRUB2. Options
> for Xen and modules are passed separately which simplifies command line 
> editing
> in boot loader and parsing. multiboot2 protocol is very flexible and could be
> easily extended in the future if a need arises. Support for secure boot and
> shim loader could be added. However, it was not implemented yet. Probably
> linuxefi module could be used as a reference or even as a base for 
> development.
> However, I do not know are there plans to support such solution by GRUB2
> community. Currently, support for native PE images signatures and GPG 
> signatures
> is under development for GRUB2 upstream.
> 
GPG signatures are supported already. My plan is as follows:
- Implement PE signatures upstream.
- Uplift as much of secureboot to upstream as policy permits. I would
like to be in partnership over this with some distro people so that they
can carry remaining part (unless FSF allows secureboot per policy)
> There is still open question that ExitBootServices() should be called by GRUB2
> loader or by loaded image itself on EFI platform. UEFI spec 2.4 states in many
> places that it is "OS loader" or "Operating System" responsibility. However,
> I think that "OS loader" should be understood as a integral piece of 
> "Operating
> System" responsible for its load into memory without usage of any additional
> loader like GRUB2.
"Operating system" isn't just kernel. Everything you get in base install
is "Operating system" including i.a. shell or bootloader.
However this is kind of decision that couldn't be taken based on spec
alone. The bugs in real-world EFI implementations play more role in
design solutions that EFI specification.
> There is also third solution for issues with ExitBootServices(). In case
> of multiboot2 protocol OS could request that EFI should be left as is.
> Solution was proposed by Vladimir and I think that it makes sense.
I will write the specification draft for it then but probably not today.
> However,
> this does not solve problem with ExitBootServices() in case of other
> boot loaders/protocols.
multiboot2 was designed in a way not to be limited to GRUB2. It can be
added to other bootloaders as well.
> So we should take a decision accordingly to above
> considerations in regards to linux, chainloader and similar stuff.
> 
> Daniel
> 




signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

Mail is big, I think I got your essential points but I didn't read it whole.
On 21.10.2013 14:57, Daniel Kiper wrote:
> Hi,
> 
> During work on multiboot2 protocol support for Xen it was discovered
> that memory map passed via relevant tag could not represent wide range
> of memory types available on EFI platforms. Additionally, GRUB2
> implementation calls ExitBootServices() on them just before jumping
> into loaded image. In this situation loaded system could not clearly
> identify reserved memory regions, EFI runtime services regions and others.
> 
Will a multiboot2 tag with whole EFI memory map solve your problem?
> Additionally, it should be mentioned that there is no possibility or it could
> be very difficult to implement secure boot on EFI platforms using GRUB2 as 
> boot
> loader because, as it was mentioned earlier, it calls ExitBootServices().
> 
GRUB has generic support for signing kernels/modules/whatsoever using
GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
method doesn't have any controversy associated with EFI stuff but at
this particular case does exactly the same thing: verify signature.
multiboot2 is mainly memory structure specification so probably how the
files are checked is outside of its scope. But it's possible to add
specification on how to embed signatures in kernel.



signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.10.2013 22:53, Seth Goldberg wrote:
> 
> 
> Quoting Daniel Kiper, who wrote the following on Mon, 21 Oct 2013:
> 
>> Hi,
>>
>> During work on multiboot2 protocol support for Xen it was discovered
>> that memory map passed via relevant tag could not represent wide range
>> of memory types available on EFI platforms. Additionally, GRUB2
>> implementation calls ExitBootServices() on them just before jumping
>> into loaded image. In this situation loaded system could not clearly
>> identify reserved memory regions, EFI runtime services regions and
>> others.
> 
>   Yes, that is exactly why we added full support to pass the entire UEFI
> memory map via a new tag.
> 
Can you send this patch? Or provide a link to publically available
source? I think we can accept it with probably just minor changes.



signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.10.2013 23:16, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Mail is big, I think I got your essential points but I didn't read it whole.
> On 21.10.2013 14:57, Daniel Kiper wrote:
>> Hi,
>>
>> During work on multiboot2 protocol support for Xen it was discovered
>> that memory map passed via relevant tag could not represent wide range
>> of memory types available on EFI platforms. Additionally, GRUB2
>> implementation calls ExitBootServices() on them just before jumping
>> into loaded image. In this situation loaded system could not clearly
>> identify reserved memory regions, EFI runtime services regions and others.
>>
> Will a multiboot2 tag with whole EFI memory map solve your problem?
I added such a tag in documentation and wrote a patch for it (attached).
Awaiting for someone to test it to commit

=== modified file 'grub-core/loader/i386/multiboot_mbi.c'
--- grub-core/loader/i386/multiboot_mbi.c	2013-10-14 14:33:44 +
+++ grub-core/loader/i386/multiboot_mbi.c	2013-10-22 06:57:45 +
@@ -36,6 +36,10 @@
 #include 
 #include 
 
+#ifdef GRUB_MACHINE_EFI
+#include 
+#endif
+
 /* The bits in the required part of flags field we don't support.  */
 #define UNSUPPORTED_FLAGS			0xfff8
 
@@ -579,6 +583,12 @@
   ptrdest += sizeof (struct grub_vbe_mode_info_block);
 #endif
 
+#ifdef GRUB_MACHINE_EFI
+  err = grub_efi_finish_boot_services (NULL, NULL, NULL, NULL, NULL);
+  if (err)
+return err;
+#endif
+
   return GRUB_ERR_NONE;
 }
 

=== modified file 'grub-core/loader/multiboot.c'
--- grub-core/loader/multiboot.c	2013-09-23 11:35:33 +
+++ grub-core/loader/multiboot.c	2013-10-22 06:51:30 +
@@ -131,12 +131,6 @@
   if (err)
 return err;
 
-#ifdef GRUB_MACHINE_EFI
-  err = grub_efi_finish_boot_services (NULL, NULL, NULL, NULL, NULL);
-  if (err)
-return err;
-#endif
-
 #if defined (__i386__) || defined (__x86_64__)
   grub_relocator32_boot (grub_multiboot_relocator, state, 0);
 #else

=== modified file 'grub-core/loader/multiboot_mbi2.c'
--- grub-core/loader/multiboot_mbi2.c	2013-10-14 14:33:44 +
+++ grub-core/loader/multiboot_mbi2.c	2013-10-22 06:57:58 +
@@ -295,9 +295,55 @@
 #endif
 }
 
+#ifdef GRUB_MACHINE_EFI
+
+static grub_efi_uintn_t efi_mmap_size = 0;
+
+/* Find the optimal number of pages for the memory map. Is it better to
+   move this code to efi/mm.c?  */
+static void
+find_efi_mmap_size (void)
+{
+  efi_mmap_size = (1 << 12);
+  while (1)
+{
+  int ret;
+  grub_efi_memory_descriptor_t *mmap;
+  grub_efi_uintn_t desc_size;
+  grub_efi_uintn_t cur_mmap_size = efi_mmap_size;
+
+  mmap = grub_malloc (cur_mmap_size);
+  if (! mmap)
+	return;
+
+  ret = grub_efi_get_memory_map (&cur_mmap_size, mmap, 0, &desc_size, 0);
+  grub_free (mmap);
+
+  if (ret < 0)
+	return;
+  else if (ret > 0)
+	break;
+
+  if (efi_mmap_size < cur_mmap_size)
+	efi_mmap_size = cur_mmap_size;
+  efi_mmap_size += (1 << 12);
+}
+
+  /* Increase the size a bit for safety, because GRUB allocates more on
+ later, and EFI itself may allocate more.  */
+  efi_mmap_size += (3 << 12);
+
+  efi_mmap_size = ALIGN_UP (efi_mmap_size, 4096);
+}
+#endif
+
 static grub_size_t
 grub_multiboot_get_mbi_size (void)
 {
+#ifdef GRUB_MACHINE_EFI
+  if (!efi_mmap_size)
+find_efi_mmap_size ();
+#endif
   return 2 * sizeof (grub_uint32_t) + sizeof (struct multiboot_tag)
 + (sizeof (struct multiboot_tag_string)
+ ALIGN_UP (cmdline_size, MULTIBOOT_TAG_ALIGN))
@@ -318,6 +364,10 @@
 + ALIGN_UP (sizeof (struct multiboot_tag_old_acpi)
 		+ sizeof (struct grub_acpi_rsdp_v10), MULTIBOOT_TAG_ALIGN)
 + acpiv2_size ()
+#ifdef GRUB_MACHINE_EFI
++ ALIGN_UP (sizeof (struct multiboot_tag_efi_mmap)
+		+ efi_mmap_size, MULTIBOOT_TAG_ALIGN)
+#endif
 + sizeof (struct multiboot_tag_vbe) + MULTIBOOT_TAG_ALIGN - 1
 + sizeof (struct multiboot_tag_apm) + MULTIBOOT_TAG_ALIGN - 1;
 }
@@ -760,6 +810,28 @@
   }
 #endif
 
+#ifdef GRUB_MACHINE_EFI
+  {
+struct multiboot_tag_efi_mmap *tag = (struct multiboot_tag_efi_mmap *) ptrorig;
+grub_efi_uintn_t efi_desc_size;
+grub_efi_uint32_t efi_desc_version;
+
+tag->type = MULTIBOOT_TAG_TYPE_EFI_MMAP;
+tag->size = sizeof (*tag) + efi_mmap_size;
+
+err = grub_efi_finish_boot_services (&efi_mmap_size, tag->efi_mmap, NULL,
+	 &efi_desc_size, &efi_desc_version);
+if (err)
+  return err;
+tag->descr_size = efi_desc_size;
+tag->descr_vers = efi_desc_version;
+tag->size = sizeof (*tag) + efi_mmap_size;
+
+ptrorig += ALIGN_UP (tag->size, MULTIBOOT_TAG_ALIGN)
+  / sizeof (grub_properly_aligned_t);
+  }
+#endif
+
   {
 struct multiboot_tag *tag = (struct multiboot_tag *) ptrorig;
 tag->type = MULTIBOOT_TAG_TYPE_END;

=== modified file 'include/mu

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.10.2013 16:51, Konrad Rzeszutek Wilk wrote:
> If you use 'linux' module, it will call ExitBootService.
> If you use 'multiboot' module, it will call ExitBootService too.
> 
> So if you don't want to the module to call 'grub_efi_finish_boot_services'
> you need to use 'linuxefi' :-)
That's a very limited logic. Commands can be modified and protocols can
be extended.
There was only one e-mail explaining the needs and I answered with
proposing possible solutions yet the 2 e-mails in question were
completely ignored.
What's the need behind not calling ExitBootService? This is a point
which was never really explained to me. EFI specification specifically
tells to call ExitBootService.



signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.10.2013 18:01, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 03:42:42PM +, Woodhouse, David wrote:
>> On Tue, 2013-10-22 at 16:32 +0100, Matthew Garrett wrote:
>>>
>>> There are two problems with this:
>>>
>>> 1) The kernel will only boot if it's signed with a key in db, not a key
>>> in MOK.
>>> 2) grub will read the kernel, but the kernel will have to read the
>>> initramfs using EFI calls. That means your initramfs must be on a FAT
>>> partition.
>>>
>>> If you're happy with those limitations then just use the chainloader
>>> command. If you're not, use the linuxefi command.
>>
>> Well, we're talking about booting the Xen hypervisor aren't we?
>>
>> So yes, there are reasons the Linux kernel uses the 'boot stub' the way
>> it does, but I'm not sure we advocate that Xen should emulate that in
>> all its 'glory'?
> 
> Right, I think that sensible mixture of multiboot2 protocol (it is needed
> to pass at least modules list to Xen; IIRC, linuxefi uses Linux Boot protocol
> for it) with extension proposed by Vladimir and something similar to linuxefi
> command will solve our problem (I proposed it in my first email). Users which
> do not need SB may use upstream GRUB2 and others could use
> 'multiboot2efi extension'.
I think it's possible to handle secureboot with same multiboot2 base.
Correct me if I'm wrong but secureboot doesn't specify format of
signaatures, only that they should be present and checked.
So why not to make that the only difference between secureboot-enabled
and not-secureboot-enabled versions is that former enforces signatures
even against user will. This will reduce the policy-charger patch to
about 100 lines.
The signature format to use can be discussed as well. My main problem
with pe signatures as used for EFI is their apparent complexity but I
haven't looked in them yet.
> 
> Daniel
> 
> ___
> Grub-devel mailing list
> grub-de...@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 




signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.10.2013 18:14, Daniel Kiper wrote:
>> > Are you (going to be) in Edinburgh? Matthew was just explaining a bunch
>> > of this stuff to me, it might be useful for you to get it from the
>> > horses mouth instead of laundered through my brain (which is a bit
>> > addled afterwards ;-)).
What and when happens in Edinburgh? It's close enough to me and I might
be able to free myself if it's for collaboration with xen. I'd also like
to discuss grant tables version issue for pvgrub2 (which is almost ready)



signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.10.2013 18:51, Daniel Kiper wrote:
> On Tue, Oct 22, 2013 at 04:36:04PM +, Maliszewski, Richard L wrote:
>> I may be off-base, but when I was wading through the grub2 code earlier
>> this year, it looked to me like it was going to refuse to launch anything
>> via MB1 or MB2 if the current state was a secure boot launch.
> 
> Are you talking about upstream GRUB2 or GRUB2 with tons of distros
> patches including linuxefi one. If later one it could be the case.
> 
> Daniel
> 
secureboot patch in its current state has only one goal: make microsoft
sign existing image and load linux. If we integrate it with GRUB
signatures check (as far as GNU policy permits but rest would be tiny)
then it will be a matter of choosing which way xen is going to be
signed. I'd recommend GnuPG detached signature (xen and xen.sig) but
don't insist on it.



signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.10.2013 19:12, Andrey Borzenkov wrote:
> В Mon, 21 Oct 2013 23:16:24 +0200
> Vladimir 'φ-coder/phcoder' Serbinenko  пишет:
> 
>> GRUB has generic support for signing kernels/modules/whatsoever using
>> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
>> method doesn't have any controversy associated with EFI stuff but at
>> this particular case does exactly the same thing: verify signature.
>> multiboot2 is mainly memory structure specification so probably how the
>> files are checked is outside of its scope. But it's possible to add
>> specification on how to embed signatures in kernel.
>>
> 
> I'm a bit skeptical here. Given that
> 
> - EFI secure boot will still be needed to handle Windows
> - kernel can be launched directly as EFI application
> - there are other bootloaders with secure boot support
> 
> distributions will likely need to carry on EFI secure boot support. At
> which point it is not clear what advantages second, parallel,
> infrastructure for the sake of single application will bring.
> 
Using PE signatures is possible as I already said which invalidates your
points.
> The most compelling reason would be allowing module loading (which is
> currently disabled by secure boot patches).
> 




signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.10.2013 09:43, Daniel Kiper wrote:
> On Mon, Oct 21, 2013 at 11:16:24PM +0200, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> Mail is big, I think I got your essential points but I didn't read it whole.
>> On 21.10.2013 14:57, Daniel Kiper wrote:
>>> Hi,
>>>
>>> During work on multiboot2 protocol support for Xen it was discovered
>>> that memory map passed via relevant tag could not represent wide range
>>> of memory types available on EFI platforms. Additionally, GRUB2
>>> implementation calls ExitBootServices() on them just before jumping
>>> into loaded image. In this situation loaded system could not clearly
>>> identify reserved memory regions, EFI runtime services regions and others.
>>>
>> Will a multiboot2 tag with whole EFI memory map solve your problem?
>>> Additionally, it should be mentioned that there is no possibility or it 
>>> could
>>> be very difficult to implement secure boot on EFI platforms using GRUB2 as 
>>> boot
>>> loader because, as it was mentioned earlier, it calls ExitBootServices().
>>>
>> GRUB has generic support for signing kernels/modules/whatsoever using
>> GnuPG signatures. You'd just have to ship xen.sig and kernel.sig. This
>> method doesn't have any controversy associated with EFI stuff but at
>> this particular case does exactly the same thing: verify signature.
>> multiboot2 is mainly memory structure specification so probably how the
>> files are checked is outside of its scope. But it's possible to add
>> specification on how to embed signatures in kernel.
> 
> I think that EFI signatures should be supported because they are quite
> common right now. However, I think that it is also worth to support
> GnuPG signatures. This way anybody will be able to choose good solution
> for a given case.
> 
Agreed.

> Daniel
> 




signature.asc
Description: OpenPGP digital signature

Re: EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.10.2013 09:05, Daniel Kiper wrote:
> Thanks. Could you send me a pointer to current multiboot2 protocol docs?
It's managed as "multiboot2" branch in our repo:
http://git.savannah.gnu.org/cgit/grub.git
Note: we're in process of moving from bzr to git which may cause the
link to change.



signature.asc
Description: OpenPGP digital signature

Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.10.2013 15:13, Konrad Rzeszutek Wilk wrote:
>  - not make an ExitBootServices call - which it does right now in the Solaris
>GRUB2 case and in the Fedora GRUB2 case.
What about having a special tag in multiboot2 file header "RKEBSIHE":
"request to keep EFI boot services" and then bootloader will pass
another (empty, other than header) info tag: "Beware of EFI"
>  - Do the signature verification (hand-waving which one - probably both).
Can someone throw me the link on the EFI signature specification? Can't
really find it now.
>  - Pack the right bits in the multiboot2 structure.
As soon as my patch is tested for compatibility with Solaris, I commit
it. Tell me if you need sth else.



signature.asc
Description: OpenPGP digital signature

Re: [Xen-devel] EFI and multiboot2 devlopment work for Xen

[Vladimir 'φ-coder/phcoder' Serbinenko]

> GrUB - which iiuc stays in memory
> after transferring control - could export its file system support to its
> descendants).

Xen shouldn't need to load any file after multiboot2 entry point. The
needed files would already be in memory with pointers to them passed.
If you insist on being able to load directly from EFI, then IMO the best
way is to have a PE executable with one of sections containing Xen and
code which would load remaining files to memory and call common entry point.




signature.asc
Description: OpenPGP digital signature

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

> I'm not a fan of Coreboot having invented its own nonstandard hacks, but
> I guess it is pretty much unavoidable.
It's completely avoidable. The stub can copy this information to
standard framebuffer info structure. The only missing thing is to apply
patch by cjwatson or mjg59 (I'm not sure now who wrote it) for having an
ID for linear framebuffer which implies no specific hardware (it can be
any) or firmware (coreboot doesn't provide nay additional info or callback).

Please don't apply this patch it will break SeaBIOS booting with VGABIOS.



signature.asc
Description: OpenPGP digital signature

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.09.2014 00:18, ron minnich wrote:
> Vladimir can you point me to that patch? This sounds interesting.
> 
https://lkml.org/lkml/2010/8/25/190

> ron
> 




signature.asc
Description: OpenPGP digital signature

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.09.2014 00:31, H. Peter Anvin wrote:
> On 09/05/2014 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 06.09.2014 00:18, ron minnich wrote:
>>> Vladimir can you point me to that patch? This sounds
>>> interesting.
>>>
>> https://lkml.org/lkml/2010/8/25/190
>>
> 
> I believe *most* of this patch has already gotten merged as we now use
> simplefb on x86 as well.  So all we need is probably the ID.
>
Yes, efifb has the same semantics. We just need some ID with clear
documentation saying sth like "implies framebuffer without anything
else" so that noone will get an idea to plug e.g. vga hooks into it.

>   -hpa
> 
> 




signature.asc
Description: OpenPGP digital signature