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 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 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 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
43 matches
Mail list logo
