On Fri 2013-06-21 09:42:35, H. Peter Anvin wrote:
> On 06/21/2013 07:21 AM, Borislav Petkov wrote:
> > On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote:
> >> If you cap it you are basically imposing a constraint on the firmware
> >> and may not run properly (or at least have to turn o
On 06/21/2013 07:21 AM, Borislav Petkov wrote:
> On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote:
>> If you cap it you are basically imposing a constraint on the firmware
>> and may not run properly (or at least have to turn off EFI runtime
>> calls with all that implies.)
>
> I don
On Fri, Jun 21, 2013 at 03:05:30AM -0700, H. Peter Anvin wrote:
> If you cap it you are basically imposing a constraint on the firmware
> and may not run properly (or at least have to turn off EFI runtime
> calls with all that implies.)
I don't want to cap EFI just for the fun of it but rather set
If you cap it you are basically imposing a constraint on the firmware and may
not run properly (or at least have to turn off EFI runtime calls with all that
implies.) It might be good to have a sanity check but it needs to be pretty
generous.
Borislav Petkov wrote:
>On Thu, Jun 20, 2013 at 0
On Thu, Jun 20, 2013 at 03:35:24PM -0700, H. Peter Anvin wrote:
> On 06/20/2013 11:47 AM, Borislav Petkov wrote:
> >
> > I guess we can do a top-down allocation, starting from the highest
> > virtual addresses:
> >
> > EFI_HIGHEST_ADDRESS
> > |
> > | size1
> > |
> > --> region1
> > |
> > | size2
On Wed, 19 Jun, at 06:59:02PM, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote:
> > > Ok, so it sounds like we want to *always* create both mappings but,
> > > depending on what we want, to shove down SetVirtualAddressMap a
> > > different set. And the 1:1 m
On 06/20/2013 11:47 AM, Borislav Petkov wrote:
>
> I guess we can do a top-down allocation, starting from the highest
> virtual addresses:
>
> EFI_HIGHEST_ADDRESS
> |
> | size1
> |
> --> region1
> |
> | size2
> |
> --> region2
>
> ...
>
> and we make EFI_HIGHEST_ADDRESS be the same absolute num
On 06/19/2013 09:59 AM, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote:
>>> Ok, so it sounds like we want to *always* create both mappings but,
>>> depending on what we want, to shove down SetVirtualAddressMap a
>>> different set. And the 1:1 map will be th
On Thu, Jun 20, 2013 at 07:17:31PM +0100, Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 08:14:45PM +0200, Borislav Petkov wrote:
> > On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
> > > Because Windows passes high addresses to SetVirtualAddressMap(), and
> > > because if you ca
On Thu, Jun 20, 2013 at 08:14:45PM +0200, Borislav Petkov wrote:
> On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
> > Because Windows passes high addresses to SetVirtualAddressMap(), and
> > because if you can imagine firmware developers getting it wrong then
> > firmware develope
On Thu, Jun 20, 2013 at 07:10:15PM +0100, Matthew Garrett wrote:
> Because Windows passes high addresses to SetVirtualAddressMap(), and
> because if you can imagine firmware developers getting it wrong then
> firmware developers will have got it wrong.
Can we reversely assume that if we'd used fix
On Thu, Jun 20, 2013 at 08:08:08PM +0200, Borislav Petkov wrote:
> On Thu, Jun 20, 2013 at 06:12:10PM +0100, Matthew Garrett wrote:
> > On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote:
> >
> > > If we can detect the Macs, we can make this decision automatic. And
> > > since no Mac
On Thu, Jun 20, 2013 at 06:12:10PM +0100, Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote:
>
> > If we can detect the Macs, we can make this decision automatic. And
> > since no Mac boots windoze, a single DMI check of the sort "if (Mac)"
> > should suffice
On Thu, Jun 20, 2013 at 07:01:24PM +0200, Borislav Petkov wrote:
> If we can detect the Macs, we can make this decision automatic. And
> since no Mac boots windoze, a single DMI check of the sort "if (Mac)"
> should suffice.
Yes, we can special-case Macs. But since our behaviour is then obviously
On Thu, Jun 20, 2013 at 05:54:26PM +0100, Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote:
>
> > Unless you can think of the way out of this, we seem to have the stark
> > choice of behave like windows or allow kexec. For the server market,
> > kexec wins,
On Thu, Jun 20, 2013 at 09:46:15AM -0700, James Bottomley wrote:
> Unless you can think of the way out of this, we seem to have the stark
> choice of behave like windows or allow kexec. For the server market,
> kexec wins, so either we find a way not to have to make the choice or we
> do somethin
On Thu, Jun 20, 2013 at 06:44:46PM +0200, Jiri Kosina wrote:
> So if we properly detect those (and only those), we mimic Windows
> completely, right?
No. Windows passes addresses above the phys/virt split to
SetVirtualAddressMap().
--
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe fr
On Thu, 2013-06-20 at 17:29 +0100, Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote:
>
> > Can't we detect Macs from some of the UEFI strings at boot time and do
> > the right thing with the boot switch (which can be overriden from the
> > kernel command lin
On Thu, 20 Jun 2013, Matthew Garrett wrote:
> > Can't we detect Macs from some of the UEFI strings at boot time and do
> > the right thing with the boot switch (which can be overriden from the
> > kernel command line if we get it wrong)?
>
> Yes, and then our behaviour differs from Windows
How s
On Thu, Jun 20, 2013 at 07:53:39AM -0700, James Bottomley wrote:
> Can't we detect Macs from some of the UEFI strings at boot time and do
> the right thing with the boot switch (which can be overriden from the
> kernel command line if we get it wrong)?
Yes, and then our behaviour differs from Win
On Thu, 2013-06-20 at 10:44 +0100, Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 11:33:37AM +0200, Borislav Petkov wrote:
> > This will break the Macs so maybe we can do
> >
> > efi=no_11_map
> >
> > so the Macs can still boot but use the 1:1 map by default.
>
> I'm going to guess that there
On Thu, 20 Jun 2013, Matthew Garrett wrote:
> > This will break the Macs so maybe we can do
> >
> > efi=no_11_map
> >
> > so the Macs can still boot but use the 1:1 map by default.
>
> I'm going to guess that there are more people running unmodified Linux
> kernels on Macs than there are peopl
On Thu, Jun 20, 2013 at 11:33:37AM +0200, Borislav Petkov wrote:
> This will break the Macs so maybe we can do
>
> efi=no_11_map
>
> so the Macs can still boot but use the 1:1 map by default.
I'm going to guess that there are more people running unmodified Linux
kernels on Macs than there are p
On Thu, Jun 20, 2013 at 11:22:37AM +0200, Ingo Molnar wrote:
> > > Cool - and supposedly this will work in a Mac environment as well? Would
> > > be very nice to avoid fundamentally fragile system specific quirks for
> > > something as fundamental as the EFI runtime memory mapping model ...
> >
* Matthew Garrett wrote:
> On Thu, Jun 20, 2013 at 11:13:21AM +0200, Ingo Molnar wrote:
>
> > Cool - and supposedly this will work in a Mac environment as well? Would
> > be very nice to avoid fundamentally fragile system specific quirks for
> > something as fundamental as the EFI runtime mem
On Thu, Jun 20, 2013 at 11:13:21AM +0200, Ingo Molnar wrote:
> Cool - and supposedly this will work in a Mac environment as well? Would
> be very nice to avoid fundamentally fragile system specific quirks for
> something as fundamental as the EFI runtime memory mapping model ...
Apple is the on
* Matthew Garrett wrote:
> On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
> > * Borislav Petkov wrote:
> > > And yet there are the Macs which reportedly cannot stomach this.
> >
> > Do we know why?
>
> I got lost in a maze of pointer arithmetic. There seems to be an
> assumptio
On Wed, Jun 19, 2013 at 12:38:24PM -0500, H. Peter Anvin wrote:
> I thought that was the plan?
Well, currently if I'm booted with "efi=1:1_map" I'm creating only the
1:1 mapping in ->trampoline_pgd and switching the pagetable only then.
Otherwise, I'm using the high, ioremapped mappings - i.e., wh
On 06/19/2013 12:37 PM, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote:
>> On 06/19/2013 08:02 AM, Borislav Petkov wrote:
>>>
>>> And yet there are the Macs which reportedly cannot stomach this.
>>>
>> No, the reports are that if you use the 1:1 map as the p
On Wed, Jun 19, 2013 at 12:25:42PM -0500, H. Peter Anvin wrote:
> On 06/19/2013 08:02 AM, Borislav Petkov wrote:
> >
> > And yet there are the Macs which reportedly cannot stomach this.
> >
> No, the reports are that if you use the 1:1 map as the primary address
> on Macs the drivers fail... not
On 06/19/2013 08:02 AM, Borislav Petkov wrote:
>
> And yet there are the Macs which reportedly cannot stomach this.
>
No, the reports are that if you use the 1:1 map as the primary address
on Macs the drivers fail... not that you can't have a 1:1 map.
-hpa
--
To unsubscribe from this l
On Wed, Jun 19, 2013 at 05:48:22PM +0100, Matthew Garrett wrote:
> > Ok, so it sounds like we want to *always* create both mappings but,
> > depending on what we want, to shove down SetVirtualAddressMap a
> > different set. And the 1:1 map will be the optional one which we give
> > SetVirtualAddres
On Wed, 2013-06-19 at 18:38 +0200, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote:
> > Yes, kexec needs a different solution.
>
> No need. If we say, "efi=use_11_map", the 1:1 map will be shoved down
> SetVirtualAddressMap. Otherwise the high mappings.
>
On Wed, Jun 19, 2013 at 06:38:04PM +0200, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote:
> > Yes, kexec needs a different solution.
>
> No need. If we say, "efi=use_11_map", the 1:1 map will be shoved down
> SetVirtualAddressMap. Otherwise the high mappin
On Wed, Jun 19, 2013 at 05:21:15PM +0100, Matthew Garrett wrote:
> Yes, kexec needs a different solution.
No need. If we say, "efi=use_11_map", the 1:1 map will be shoved down
SetVirtualAddressMap. Otherwise the high mappings.
> Because firmware images don't always update all of the pointers, and
On Wed, Jun 19, 2013 at 06:18:27PM +0200, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote:
> > But, as always, the only reliable thing to do here is to behave as
> > much like Windows as possible. Which means performing the 1:1 mapping
> > but maintaining th
On Wed, Jun 19, 2013 at 05:08:04PM +0100, Matthew Garrett wrote:
> But, as always, the only reliable thing to do here is to behave as
> much like Windows as possible. Which means performing the 1:1 mapping
> but maintaining the high mapping, and passing the high values via
> SetVirtualAddressMap.
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
> * Borislav Petkov wrote:
> > And yet there are the Macs which reportedly cannot stomach this.
>
> Do we know why?
I got lost in a maze of pointer arithmetic. There seems to be an
assumption that nvram writes should be forbidden if i
On Wed, Jun 19, 2013 at 03:02:25PM +0200, Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
> > I hope making it a weird boot option is not the end plan, there's
> > little point in _not_ enabling 1:1 mappings by default eventually:
> > the 1:1 mapping is suppose
On Wed, Jun 19, 2013 at 03:04:34PM +0200, Ingo Molnar wrote:
> Do we know why?
Well, according to mjg59 some Macs break if we don't give them a map
which uses high addresses.
I can imagine flipping the meaning of this option to be on by default
and "efi=no_11_map" to disable the 1:1 map for those
* Borislav Petkov wrote:
> On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
> > I hope making it a weird boot option is not the end plan, there's
> > little point in _not_ enabling 1:1 mappings by default eventually:
> > the 1:1 mapping is supposed to emulate a "Windows compatible" E
On Wed, Jun 19, 2013 at 02:52:43PM +0200, Ingo Molnar wrote:
> I hope making it a weird boot option is not the end plan, there's
> little point in _not_ enabling 1:1 mappings by default eventually:
> the 1:1 mapping is supposed to emulate a "Windows compatible" EFI
> environment better and is expec
* Borislav Petkov wrote:
> From: Borislav Petkov
>
> Hi all,
>
> this is just a snapshot of the current state of affairs. The patchset
> starts to boot successfully on real hardware now but we're far away from
> the coverage we'd like to have before we even consider upstreaming it.
Looks pre
From: Borislav Petkov
Hi all,
this is just a snapshot of the current state of affairs. The patchset
starts to boot successfully on real hardware now but we're far away from
the coverage we'd like to have before we even consider upstreaming it.
And yes, considering the sick f*ck EFI is, we're ke
44 matches
Mail list logo