Clover General discussion

[apianti]

Uhm, api.. that is my point lol

 

I don't get your point then, AptioFix2 doesn't disable KASLR, only AptioFix. So finding regions that seem large enough and randomizing which one is picked is effectively the same as KASLR. Just a smaller subset of where it can be allocated. This probably means most people will only have one place to put it anyway.... I do.

 

EDIT: We can always figure out how much space we actually need too...

[mhaeuser]

I don't get your point then, AptioFix2 doesn't disable KASLR, only AptioFix. So finding regions that seem large enough and randomizing which one is picked is effectively the same as KASLR. Just a smaller subset of where it can be allocated. This probably means most people will only have one place to put it anyway.... I do.

 

EDIT: We can always figure out how much space we actually need too...

"Conditional relocation" != Use the traditional reloc block when needed, but reloc only what needs to be reloc'd, back where it belongs. KASLR does noot need to be disabled.

[apianti]

"Conditional relocation" != Use the traditional reloc block when needed, but reloc only what needs to be reloc'd, back where it belongs. KASLR does noot need to be disabled.

 

I don't want to disable KASLR but I also don't want to use relocation blocks. What happens if it chooses a slide where there's a runtime area? Even if you use a relocation you just wiped out a runtime area. So how do you prevent that without deciding which slides are going to valid?

 

EDIT: Which is why since no runtime is being relocated, do not use AptioFix.

EDIT2: And explains broken NVRAM with AptioFix, an RT_Data buffer for SMM is probably being overwritten.

EDIT3: The current hang at "does printf work??" may also actually be related. Maybe it disregarded and overwrote a runtime area because it believe it to be moved into the kernel? No, because it has the memory map and those are marked as MMIO at that point.

[mhaeuser]

I also don't want to use relocation blocks.

 

Erm... ok.

 

What happens if it chooses a slide where there's a runtime area?

 

And what happens if your guessed block size is too small? There is no single best solution... I would just error-quit when a RT region is in the way.

[apianti]

And what happens if your guessed block size is too small? There is no single best solution... I would just error-quit when a RT region is in the way.

 

Like I said we could determine the amount of pages, but I think that doesn't really matter anyway. AptioFix only uses 0x8000 + runtime pages, which are no longer even moved. So deciding on a reasonable amount of space is fine and any region that has a slide in it that allows for at least that much space, that slide should be put in a list, then a value should be randomly picked from the list. And what's the difference between when there's not enough space and just error quitting there or quitting later? Or what if there truly is only one region that doesn't have runtime region blocking it? It works now, maybe just let user select it. And be done.

[mhaeuser]

And what's the difference between when there's not enough space and just error quitting there or quitting later?

 

Code complexity, backwards compatibility and independence from the amount and location of BootServices memory.

[apianti]

Code complexity, backwards compatibility and independence from the amount and location of BootServices memory.

 

How so? You'd need to allocate the relocation blocks before boot.efi. So you'd still have to work around boot services memory, and you'd still need to know how much you'd need to relocate... So I don't see a difference, I actually think your method is more complicated. And backwards compatible to what? Lion? Who's running Lion that can't just use an older version of clover?

[Guest]

@apianti

So x99 rigs can’t have a proper working nvram stored?

Or is only an Asus x99 firmware problem in your opinion/experience?

Thank you

[mhaeuser]

How so? You'd need to allocate the relocation blocks before boot.efi.

 

No, why would you? Overwrite AllocatePages(), call the original AllocatePages() and if it returns the appropiate error code (iirc EFI_OUT_OF_RESOURCES, but would need to check), just allocate elsewhere and store information about where it is now and where it should be copied to on kernel entry.

 

And backwards compatible to what? Lion? Who's running Lion that can't just use an older version of clover?

 

Yes, Lion and lower. I don't want this "use driver x for this version of macOS, use driver y for that version of macOS", I want one to rule them all.

Btw, vit checked boot.efi and found out that "slide=" is not available with safe mode. Imo now it's obvious which way to go

[apianti]

No, why would you? Overwrite AllocatePages(), call the original AllocatePages() and if it returns the appropiate error code (iirc EFI_OUT_OF_RESOURCES, but would need to check), just allocate elsewhere and store information about where it is now and where it should be copied to on kernel entry.

 

How is that not allocating it before boot.efi, and how do you know you are not now allocating that region inside of where the slide was supposed to be? Figure out the slide and not allocate in that region, but how big is the region?? Then you go through all this to fail boot because there's a runtime region there........

 

Yes, Lion and lower. I don't want this "use driver x for this version of macOS, use driver y for that version of macOS", I want one to rule them all.

Btw, vit checked boot.efi and found out that "slide=" is not available with safe mode. Imo now it's obvious which way to go

 

Why is safe mode even needed? Why can't you just use -s and rebuild the cache? Or the recovery...? I could care less about Lion, it was released like seven years ago, and they can use AptioFix from an older package.

@apianti

So x99 rigs can’t have a proper working nvram stored?

Or is only an Asus x99 firmware problem in your opinion/experience?

Thank you

 

Unsure. X99 is one of the worst platforms, ASUS Z97 introduced a whitelist, which is probably also in ASUS X99, did you ever have working NVRAM? Because if you did then get the newest firmware and replace the Nvram modules with the ones from the working firmware and reflash, or downgrade. You can try writing to one of the whitelisted variables and see if that changes it (look at the solution for the UEFI topic for the NVRAM from vit9696, gives the whitelisted vars). Write to like BootOrder or something, by adding more to it.

 

EDIT: You are using the newest AptioFix2, right? Did you try setting slide?

[mhaeuser]

How is that not allocating it before boot.efi

 

boot.efi is what is calling AllocatePages(), so how could it possibly be before boot.efi? o_O

 

and how do you know you are not now allocating that region inside of where the slide was supposed to be?

 

I don't, but I can use AllocatedPagesFromTop to be a bit safer. You are constantly outlining flaws with my approach, but forget that yours has very similiar ones, except that it breaks < Lion and safe mode. I prefer to not cut features just because "relocation feels wrong". Again, there is no perfect solution, but I see that mine is more likely to work for older OSes, more likely to support safe mode and more likely to find appropiate memory as BS_data and BS_code plainly do not matter. What if there is not a single region big enough to hold the estimation you've made, but it could if BS_* was gone?

[apianti]

boot.efi is what is calling AllocatePages(), so how could it possibly be before boot.efi? o_O

 

I mean like allocating it before runtime, as in boot time. You still need to know how big the region needed for the kernel is or you could overwrite your relocation regions because they could be allocated in the region that was for the kernel.

 

I don't, but I can use AllocatedPagesFromTop to be a bit safer. You are constantly outlining flaws with my approach, but forget that yours has very similiar ones, except that it breaks < Lion and safe mode. I prefer to not cut features just because "relocation feels wrong". Again, there is no perfect solution, but I see that mine is more likely to work for older OSes, more likely to support safe mode and more likely to find appropiate memory as BS_data and BS_code plainly do not matter. What if there is not a single region big enough to hold the estimation you've made, but it could if BS_* was gone?

 

I never said relocation feels wrong, I said that it still has the exact same issues as not using it, which is that you need to know how much memory you need and where the slide is. So what is the point of doing that if you still need to do the same stuff plus more. If memory was just all allocated top down, then it would not be an issue at all, 0x100000 would be free for previous versions, and a slide should be pretty easy to get without doing anything. I have tested this on my Z77, Z170, Z270, virtual box, and QEMU with multiple firmwares. They all have almost all of the memory from 0x100000 to 0xE0000000 free (except for the virtual machines cause I only used 1GB of RAM).

 

EDIT: That is my solution, what I was suggesting is just a temporary stop gap to prevent failure on boot when the user does not supply a slide value.

EDIT2: Obviously, v2 is beyond screwed memory wise, and that is the real issue....

[Funky frank]

Most sexy kext of the day: AppleGPUWrangler

 

On my B85M-G / B85 chipset, since recent clover / optiofix2, I also can store efi variables without emuvariable.efi. 

 

I now tried Lilu and intelgraphicsfixup, but these extensions seem to do nothing at all, still firefox video is freezing while using nvidia + hd4600 at once

[apianti]

Most sexy kext of the day: AppleGPUWrangler

 

On my B85M-G / B85 chipset, since recent clover / optiofix2, I also can store efi variables without emuvariable.efi. 

 

I now tried Lilu and intelgraphicsfixup, but these extensions seem to do nothing at all, still firefox video is freezing while using nvidia + hd4600 at once

 

I think the problem with HD3000/4000 GPUs is to do with a reserved memory region setup for them but that is destroyed by AptioFix. I'm guessing you're fine if it's just NVIDIA right?

[Guest]

@apianti

Yes i am using version included in latest clover R.4369

Without slide=128 i have printf error as i said before

 

And no, nvram never worked for me in different asus rigs (c612/x99) and in all firmware i have tested from asus

 

——————

 

EDIT: You are using the newest AptioFix2, right? Did you try setting slide?

[mhaeuser]

Quote order is messed up... fml, I hate quoting here.

 

I mean like allocating it before runtime, as in boot time. You still need to know how big the region needed for the kernel is or you could overwrite your relocation regions because they could be allocated in the region that was for the kernel.

 

Yes, I admited that is a potential issue a few posts ago.

 

which is that you need to know how much memory you need and where the slide is. So what is the point of doing that if you still need to do the same stuff plus more.

 

You don't need to know how much memory is needed. When an overlap is encountered, boot must be aborted.

And no, ir's not "doing the same stuff plus more", it's simply temporarily moving regions and then moving them back (+ fix a handful of pointers) in contrast to implementing a MemoryMap scanner (dependent on an assumed kernel size), implementing a way to randomly generate a number, that that at the cost of backwards-compatibility, safe mode and possible available regions that only carry BS_*

 

I think the problem with HD3000/4000 GPUs is to do with a reserved memory region setup for them but that is destroyed by AptioFix. I'm guessing you're fine if it's just NVIDIA right?

 

Well, would you please push the fix? ;P

 

I never said relocation feels wrong

 

You said you did not want to use them with zero reasoning, so basically that was my interpretation.

[Funky frank]

I think the problem with HD3000/4000 GPUs is to do with a reserved memory region setup for them but that is destroyed by AptioFix. I'm guessing you're fine if it's just NVIDIA right?

No, not really 

[apianti]

Yes, I admited that is a potential issue a few posts ago.

 

You don't need to know how much memory is needed. When an overlap is encountered, boot must be aborted.

And no, ir's not "doing the same stuff plus more", it's simply temporarily moving regions and then moving them back (+ fix a handful of pointers) in contrast to implementing a MemoryMap scanner (dependent on an assumed kernel size), implementing a way to randomly generate a number, that that at the cost of backwards-compatibility, safe mode and possible available regions that only carry BS_*

 

You didn't see my edit about how that's not how I want the driver to work, I just want to use it as a stop-gap. Also those statements are conflicting, if you admitted that you could possibly allocate into the kernel region, then you do need to know how big it is and where it starts to avoid that... Sure you could protect against overlapping regions when you already know a region exists somewhere or is going to exist but not before... And depending on how random you want to get determines how difficult implementing a random generator is, I seem to recall that there is actually an RNG in EDK2. I think it uses RDRAND though so would only work for IB+.

 

EDIT: I said the same word twice but did not mean that word the second time.

 

Well, would you please push the fix? ;P

 

Yes, I will get to it eventually, I just don't feel very well. I think maybe that entire function might be able to be removed. There's a lot of dead and unneeded code, it really needs fixed.

 

You said you did not want to use them with zero reasoning, so basically that was my interpretation.

 

Oh, yeah, it's because of the overwriting problem, complexity, and way too much effort when it could be fixed in a much easier way by just making allocations more wisely and actually garbage collecting....

No, not really 

 

Hmmm.... I guess it's not like it's really not going to detect the integrated and not load the driver.... I'll look into it but I'm getting too sick to really do stuff now. I have a feeling it's to do with that region but I'll deal with it later. I think it's wrap myself in a blanket and watch some movies time. Medicine just making me weird....

[mhaeuser]

You didn't see my edit about how that's not how I want the driver to work, I just want to use it as a stop-gap. Also those statements are conflicting, if you admitted that you could possibly allocate into the kernel region, then you do need to know how big it is and where it starts to avoid that...

 

No, that is the point, that won't happen. It´s pretty much "hope for the best", which is the best result you can accomplish accross the AMI landscape without touching the flash chip.

Actually, our methods don't even contradict, if you have noticed.

[apianti]

No, that is the point, that won't happen. It´s pretty much "hope for the best", which is the best result you can accomplish accross the AMI landscape without touching the flash chip.

Actually, our methods don't even contradict, if you have noticed.

 

But why wouldn't we choose the easiest method then if we are hoping for the best? Getting more complicated means that there's more chance for failure, not less. And some users solution might have to be flashing because of the nature of the firmware like those X99 with 300 PCIe and 4000 NVMe slots. Those things are like in my nightmares.

[Ramalama]

slide=0

Thanks! Its working! First time i have working Nvram with aptio 5 (x299)

 

@apianti @slice and other (Sry i didnt tracked exactly who maked it possible)

Thanks to all for the awesome work, thats a beatifull birthday gift for me :-)

 

Thanks Thanks Thanks!

Nvram work!!!

Finally we dont need emulated nvram anymore!

 

Cheers :-)

[SavageAUS]

Great work @devs, Both my hacks now have functional NVRAM without EmuVAr and without rc scripts.

[Funky frank]

Hm guys, I have sometimes beeper alert while rebooting. I have to power off then. Really strange. Afterwards the boot drive selection is wrong. 

 

...Or it just hangs on restart with maximum cpu....

 

EDIT: That only happens after I disabled HD4600 in the bios

 

Pretty nasty!

[apianti]

Hm guys, I have sometimes beeper alert while rebooting. I have to power off then. Really strange. Afterwards the boot drive selection is wrong. 

 

...Or it just hangs on restart with maximum cpu....

 

EDIT: That only happens after I disabled HD4600 in the bios

 

Pretty nasty!

 

Sounds like a firmware issue. Do you maybe have a setting to disable to integrated but also set the first initialized card and its set to integrated not PCIe? Also don't disable your HD4600, I will try to fix the issue with those reserved regions in the next few days. Are you sure you also have good graphics injection?

Thanks! Its working! First time i have working Nvram with aptio 5 (x299)

 

@apianti @slice and other (Sry i didnt tracked exactly who maked it possible)

Thanks to all for the awesome work, thats a beatifull birthday gift for me :-)

 

Thanks Thanks Thanks!

Nvram work!!!

Finally we dont need emulated nvram anymore!

 

Cheers :-)

 

It was more vit9696 and Download-Fritz. But glad you got it working!

[Funky frank]

Sounds like a firmware issue. Do you maybe have a setting to disable to integrated but also set the first initialized card and its set to integrated not PCIe? Also don't disable your HD4600, I will try to fix the issue with those reserved regions in the next few days. Are you sure you also have good graphics injection?

 

No, it worked fine with the old aptiofix2 and older clover and disabled HD4600 graphics in the bios.  It beeps just before restart. It is like a protection beep against memory corruption? Sounds nasty, lot of beeps.

 

Yes injection is done properly. I now enabled hd4600 again (primary gfx is nvidia PCIe), and then set the hd4600 to a connector-less ig-platform-id. So it does not appear as opencl render anymore. Now the restarting works normally again.

 

Let me know if I can do some tests.

 

BTW: I re-tried with emuvariable.efi, no change, still beeping (hd4600 disabled).

Also re-tried aptiofix1-WTH, no change.

one question: if I have a IGPU device and ig-platform-id set in my ACPI, can I drop that whole device and its references only using clover, so I can then inject another ig-platform-id using clover?

 

Since clover won't overwrite the existing ig-platform-id... Or do I have to make an acpi patch in clover then?