AptioMemoryFix

[genzai]

7 hours ago, Slice said:

1% chance that it is possible.

look if you have some aptiofix or lowmemoryfix anywhere.

I know. I really don't. I'll post my EFI shortly (just gotta remove serial info) in case I am blind. but there is no aptio driver in my EFI anywhere. And given how broken the aptio drivers seem to be on z390 I wonder if its just better to run without. (I wonder how common it is for other boards with this chipset, will try a gigabyte designer shortly)

g\

Edited October 3, 2019 by genzai

[genzai]

Here is the EFI. Please tell me what i am missing . Hoping this can be the start of something new...

https://www.dropbox.com/s/sa27erxk9ao2tfn/EFI-CNODe2.zip?dl=0

[mhaeuser]

@genzai For reasonably new platforms this is perfectly expected and the chance is a lot higher than 1%. However, no, this is not the start of something new, we're aware of the situation and still recommend everyone to use AMF, despite the fact that you can boot without it

[genzai]

58 minutes ago, Download-Fritz said:

 we're aware of the situation and still recommend everyone to use AMF, despite the fact that you can boot without it

Wow, this is really interesting news to me. Thanks for the reply. OOC, what are the main reason(s) you recommend using AMF on a platform that doesn't /need/ it? At least in this case there are absolutely no signs of instability or other repercussions yet.

 

Thanks,

g\

[Slice]

11 hours ago, genzai said:

Here is the EFI. Please tell me what i am missing . Hoping this can be the start of something new...

https://www.dropbox.com/s/sa27erxk9ao2tfn/EFI-CNODe2.zip?dl=0

Please provide DarwinDumper report. Switch off:

- BIOS dump

- HTML report

- Intel CPU info

- OpenCL info

make it private and pack to lzma to reduce final size.

[mhaeuser]

@genzai SMM comm buffer locations at least - macOS physically moves them while the SMM side of things keeps the original physical addresses, this broke NVRAM twice (A4 with data and A5 with code). What Apple does is simply not a thing in the non-Apple world and any machine is potentially affected, until you analysed the entire SMM stack, which is simply not going to happen.

Aside from that, some firmwares write to code regions on calling, which may cause sporadic KPs

[genzai]

23 hours ago, Slice said:

Please provide DarwinDumper report. Switch off:

- BIOS dump

- HTML report

- Intel CPU info

- OpenCL info

make it private and pack to lzma to reduce final size.

 

DarwinDumper_3.0.4_05.10_01.12.15_iMac19,1_AMI_X64_4988_Unknown_18G103_dit.tar.lzma

21 hours ago, Download-Fritz said:

@genzai ...

Aside from that, some firmwares write to code regions on calling, which may cause sporadic KPs

 

Interesting, i won't pretend to understand what most of that is. What i can say is that this system has been perfectly stable after weeks of frequent use, and i don't experience any kernel panics. Still really interested in this topic.

 

g\

[Slice]

20 hours ago, genzai said:

 

DarwinDumper_3.0.4_05.10_01.12.15_iMac19,1_AMI_X64_4988_Unknown_18G103_dit.tar.lzma

 

Interesting, i won't pretend to understand what most of that is. What i can say is that this system has been perfectly stable after weeks of frequent use, and i don't experience any kernel panics. Still really interested in this topic.

 

g\

Really, there is UEFI boot, there is no MemoryFix drivers.

Memory map is follow

LoaderData 0000000000100000 - 000000000019dfff 000000000000009e 0000000000000000 000000000000000f
available  000000000019e000 - 00000000001fffff 0000000000000062 0000000000000000 000000000000000f
LoaderData 0000000000200000 - 00000000030dbfff 0000000000002edc 0000000000000000 000000000000000f
RT_data    00000000030dc000 - 0000000003a5bfff 0000000000000980 ffffff80030dc000 800000000000000f
RT_code    0000000003a5c000 - 0000000003b49fff 00000000000000ee ffffff8003a5c000 800000000000000f
LoaderData 0000000003b4a000 - 0000000014b6cfff 0000000000011023 0000000000000000 000000000000000f
available  0000000014b6d000 - 000000002bf9cfff 0000000000017430 0000000000000000 000000000000000f

So my 1% is here.

[mhaeuser]

Your 1% is inadequate in the first place, what since the introduction of KASLR kept most systems from booting was Aptio IV's missing GOP ConSplitter, which any modern-ish Aptio V board ships with OOTB.

Still, nobody is adviced to not use AMF.

[genzai]

21 minutes ago, Slice said:

Really, there is UEFI boot, there is no MemoryFix drivers.

Memory map is follow...

So my 1% is here.

So @Slice

Do you also think that i should be using a memoryfix driver? From a practical/uneducated standpoint it seems i should not. The system runs great and has no signs of instability. But i do appreciate the advice of the more knowledgable.

And on a related topic, should i begin testing this "memoryfix free" boot on my other Z390 model boards?

 

Thanks,

g\

[mhaeuser]

@genzai Look, I have tried to explain why it is a bad idea and you are obviously not interested in listening to that, and while that is fine with me personally, I cannot let you make it seem like there is nothing to not using AMF in public.

 

Any SMM code that attempts to write to buffers of a physical address cached during UEFI phase will cause KPs or memory corruption and if you are not an ambitious reverse engineerer with experience in firmware architecture, you are not capable of ensuring this cannot happen. Maybe it cannot happen on certain systems, but if it can, it will, and it will trash the system in one way or another.

 

Put your system stability in danger for all I care, but as long as you'll stress how it does not cause issues on your system, I'll be stressing this cannot be validated by plain uptime or similar testing and there is a real danger of system instability, for the possible gain of not loading a driver that runs fast enough for nobody to even notice...

[genzai]

3 minutes ago, Download-Fritz said:

@genzai Look, I have tried to explain why it is a bad idea and you are obviously not interested in listening to that, and while that is fine with me personally, I cannot let you make it seem like there is nothing to not using AMF in public.

 

Well it is not at all that i am not interested, i have stated the opposite. But i am also reporting my very practical testing, which i think should also be of interest. And I also stated that yes, i do not understand at all the implications of for instance "SMM Code". Is there something i can do to explicitly test this? I think it is fairly common knowledge that many of the MemoryFix drivers cause lots of headaches on many systems, and it often requires some testing to see which one (or combo) will work- especially with Z390- and further complicated by AMF being "retired?" from use with clover. 

 

so if not using any MemoryFix is indeed a viable option i think that is also worth noting. I would love to run some explicit tests that would cause problems if there were problems to cause, is that possible? because otherwise i am left with day to day use and there appear to be no repercussions thus far and i think that is in fact very interesting too.  

 

Thanks,

g\

[mhaeuser]

@genzai "Is there something i can do to explicitly test this?"
No, absolutely nothing. The more you invoke EFI Runtime Services such as Variable Services fine, the higher you can estimate the probability that it is fine, but you can do absolutely nothing in testing that validated it actually is fine, no. There always could be some SMI source you are not thinking of, taking a a rare path that does cause the corrupting behaviour as opposed to the usual paths.

 

"I think it is fairly common knowledge that many of the MemoryFix drivers cause lots of headaches on many systems"

This is plainly wrong, not the drivers cause the issues, but the memory layout of the host firmware. This means if there are issues *with* AMF, there will be issues *without* AMF. The likeliness of AMF causing issues with its slide detection are pretty small and the chances of AF3 causing issues are 0 (which should not imply that it is better, it is not, just that all boot failures can be attributed to the host FW memory layout, which AMF *attempts* to work around and has a much higher success than failure rate in doing that).

 

"so if not using any MemoryFix is indeed a viable option i think that is also worth noting"

It can only be viable when you can guarantee when I have said, and you cannot, and none of the other users can. A skilled Reverse Engineerer can, in the course of several weeks probably. Nobody is going to do that, especially as it'd need re-validation after each FW update. For NVRAM, there is no known AMI firmware that does not use SMM comm buffers, so they all literally fall out of the scope.

 

There is no benefit.

[Slice]

@DF

How can you explain with your point of view that legacy Clover (CloverEFI) will work without any AMF or something like that?

It happens because of better memory allocation. That's all.

[mhaeuser]

@Slice Because it, the same as much of Aptio V, uses edk2, which is the source of the ConSplitter I mentioned.

Better memory allocation is nonsense, except for a higher likeliness of slide=0 to be available (which is why I mentioned KASLR as a factor to make this point almost redundant), the allocator of most Aptio Vs is worse, please refer to X99 and other platforms that often "require" free20000.

[Pene]

On 10/3/2019 at 4:42 PM, Slice said:

1% chance that it is possible.

look if you have some aptiofix or lowmemoryfix anywhere.

Hi Slice,

 

I already wrote previously on this thread that situation on my Z390 board is the same. I also posted my full memory map some time ago also, if you wish to see it.

But for getting proper console output, HandleProtocol override is still needed, as EfiGraphicsOutputProtocol continues not to be present on ConOutHandle.

 

P.S. I am writing this solely for educational purposes, and by no means for getting into a debate whether to use it or not.

Edited October 6, 2019 by Pene

[Slice]

9 hours ago, Pene said:

Hi Slice,

 

I already wrote previously on this thread that situation on my Z390 board is the same. I also posted my full memory map some time ago also, if you wish to see it.

But for getting proper console output, HandleProtocol override is still needed, as EfiGraphicsOutputProtocol continues not to be present on ConOutHandle.

 

P.S. I am writing this solely for educational purposes, and by no means for getting into a debate whether to use it or not.

Is it possible to override only HandleProtocol? Or rewrite ConsoleSplitter?

I see, you made override HandleProtocol so this is possible. What is wrong in this way?

[Pene]

2 hours ago, Slice said:

Is it possible to override only HandleProtocol? Or rewrite ConsoleSplitter?

I see, you made override HandleProtocol so this is possible. What is wrong in this way?

a gBS->HandleProtocol override is one of the fixes included in all *Aptio*Fix* drivers:

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/OsxAptioFixDrv/OsxAptioFixDrv.c#l219

Edited October 7, 2019 by Pene

[Slice]

2 hours ago, Pene said:

a gBS->HandleProtocol override is one of the fixes included in all *Aptio*Fix* drivers:

https://sourceforge.net/p/cloverefiboot/code/HEAD/tree/OsxAptioFixDrv/OsxAptioFixDrv.c#l219

I can make it as separate EFI module. Or else include into Clover.

[mhaeuser]

I'll ask one more time to not mislead users into believing booting without relocation prevention is acceptable, because it is not.

Edited October 7, 2019 by Download-Fritz

[vit9696]

To clarify: XNU kernel will invoke RT services, which will jump to SMM that continues accessing the memory through physical addresses, and thus will effectively corrupt kernel or userspace memory.

[Slice]

It happens with or without AMF on Z390.

[mhaeuser]

@Slice If you refer to Z390's NVRAM issues, our research shows that reading (usually?) works fine and writing causes a deadlock for unknown reasons. If you have research revealing memory corruption and a plausible explaination for such, I'm excited to hear of it.

[Killuminati91]

Hey guys, im currently running into a "Couldn't allocate runtime area" problem on my new Lenovo Yoga S740 (i7-1065g7, 16gb, 512 SSD, Ice Lake).

I've read a few posts and guides and figured I should just follow this guide and set a custom slide parameter to get it to boot.

 

This is the exact message that I get:

Error allocating 0x8e368 pages at 0x000000000cccf000 alloc type 2
Couldn't allocate runtime area

 

So I follow the guide and run memmap, I end up with the following available sectors:

Available xxx-xxx 000000000000009F 000000000000000F
Available xxx-xxx 0000000000020F8A 000000000000000F
Available xxx-xxx 0000000000000001 000000000000000F
Available xxx-xxx 00000000000011C4 000000000000000F
Available 0000000100000000-00000004BABFFFFF 00000000003BAC00 000000000000000F

As you can see only the last Sector is big enough, so I chose that one even though it is really huge.

 

I use the formular found in the guide like this:

0x100000000 - 0x100000 = 0xFFF00000
0xFFF00000 / 0x200000 = 0x7FF

0x7FF converted to dec = 2047

 

So now if I use the bootargument "slide=2047" I still end up with the same error but other parameters:

Error allocating 0x8e368 pages at 0x00000000124d3000 alloc type 2
Couldn't allocate runtime area

 

Can anyone help me through this? I am kinda lost here, I tried all different aptiofix drivers.

[mhaeuser]

@Killuminati91 The kernel can never be allocated over 4 GB, which is what you are trying to do, iirc the slide value is capped to 255. Without OpenCore's DevirtualiseMMIO quirk, you'll probably not get very far, possibly not even with it.

 

You could try this with DevirtualiseMMIO=true, but we do not actively support the usage of that driver