EFI Variable Store on Aptio V (Haswell-E and up)

[goodwin_c]

I'm not worried about being right, only that the correct and best solution is found. I'll post my code when ready, as I was going to like I said. The problem I have here is that DF knows damn well I told him this exact issue almost two months ago. Then he comes on here with no code or proof of concept basically just saying what I said and that he discovered the issue, then says I have no proof. When proof is given he acts like a child. I'm here for the conversation about solving the problem, as I always have been. For the almost seven years I've been part of coding for clover, if I wanted accolades I certainly wouldn't do this because I very rarely get thanks. And believe me, without me clover would not have a large amount of features, like one configuration file instead of three, being able to use plists fully, being able to do a bunch of cool stuff with themes, basically the whole mechanism of theme.plist, custom entries, not having to use five million boot arguments to do stuff, a semi-working GUI (although there's no saving that thing but I triiiieeeed), helping dmazar with AptioFix, and that's just off the top of my head. I also maintain and administrate the project, tickets, and repositories on sourceforge. I think that DFs approval is not needed, or anyone's but my own for that matter....

 

Man, I'm not complaining anybody in any way. And my big thanks for all contribution - if you'll check Clover svn log - there are some small patches by me, so i know who is working actively

[mhaeuser]

Let's just the this over with...

 

"I think this is exactly where it belongs. You want it in private for the obvious reason."

Like keeping this {censored} thread uncluttered? I offered IRC, which just seems to be a too small of a stage for you, eh?

 

"Really so you have a working solution to everyone who has non-working NVRAM? Because I'm pretty sure that I do. What's your method? Because the method I've been working on since I brought that up before and have been rewriting v3 is that I make all RT_Data and RT_Code regions into MMIO regions, then I make copies of the RT_Code region and that is relocated. The original is still there in physical memory and the kernel is happy it got the relocated virtual code. But this is hypothetical right???"

Yikes, you accidentially solved the global vars problem , more below...

EDIT: Test results have been interpreted based on a wrong premise.

 

As to your solution: I am not sure at this point if you don't understand or are just totally incapable of describing the issue. Yes, the solution is just fine, just that I would have the original code reloc'd for the sake of not having to update gRT pointers... in fact that would have been exactly what you would have seen if you downloaded the zip I shared (but removed for bugs) a couple of posts before.

And no, I don't have a solution for everyone, currently I have the choise between writing to read-only data or executing read-write data. A kernel patch that maps all EFI regions as read-write-execute makes it work perfectly fine.

 

The issue is you throw around with "SMM Driver" without knowing what it means. All drivers inside SMRAM are SMM drivers. No driver outside of SMRAM is a SMM Driver. Drivers communicating with SMM by manually issuing a SMI are *NOT* SMM drivers. If you replace "SMM driver" in *some* spots of what you said, it starts to make at least some sense.

 

"Because I'm talking about the SMM runtime drivers that are not in SMRAM but interact with SMM. That's where the problem lies, when those modules are moved. There are physical addresses inside that pointed to where the region was previously (if you look it's at the leaked code it's a structure which means it's accessed by dereference like a pointer), and those point to buffers that were allocated for SMM."

I saw this later, so I already read other stuff of the post in detail. Can you please finally decide where the issue is now? Is it in the DXE Runtime driver that communicates with the SMM Driver, or is it in the SMM driver itself? If your answer is former, rubbish, not. the. issue.

 

"EDIT2: Also the protocol you refer to as what is causing the problems, the flash protocol, is also used in Aptio IV during NVRAM SMM communication."

Not "also", that is precisely what is the problem lol.

 

"EDIT3: The NVRAM driver is also only partially in SMM. The driver starts in DXE and installs only the variable store in SMM. I see several variables that could be corrupted by relocation depending on how they may be used later."

Not sure what you mean, cannot comment, not the issue.

 

"This sentence just doesn't even make sense. I don't know if you miswrote that or what but.... What? You are the one that said that, and then I was asking how could any variables ever be written then if it is write protected? I don't even know what you mean those from C. You mean the physical addresses I was referring to that are now no longer valid because they were moved? Because I think that's what you mean...."

I had the impression that you were swapping "C global variable" and "NVRAM variable" for my statement, but I guess you did not... You probably solved this accidentially.

Go ahead, mark all RT_code entries as MMIO to protect them from reloc and on kernel entry, change them right back to RT_code and enjoy the GPFs for writing to read-only memory.

After that, you may enjoy the show: https://github.com/practicalswift/osx/blob/master/src/xnu/osfmk/i386/AT386/model_dep.c#L643

If you ask now, where the writes go... Good question, not sure. Could imagine they go into your MMIO region, but I am not certain. They don't go where you thought they go either way.

 

"You must be in real mode in order to invoke an SMI"

No, you end up in Real Mode *after* issuing a SMI.

 

"And in order to enter it you need to write to stuff that was set up and is probably no longer there because it was moved."

So, I am certain again, you don't understand the issue. Nothing was moved out of the DXE Driver's reach and there is no issue entering SMM. I would love to say now that for Runtime DXE Drivers, all addresses are correct at all times, and while they probably are strictly speaking, there still is this impact on global variables...

EDIT: Test results have been interpreted based on a wrong premise.

 

"I was just saying that only one module interacts with SMI, not that is what is the problem."

What now? Can it reach SMM or not?

 

"The problem is the relocation of an region that was moved that deals with SMM, which is a lot of RT_Code."

Define "deals with SMM". If you mean any specifically SMM-related code, no, not the issue.

 

"I have multiple computers, so I don't know why you think I don't know what different firmwares are like...."

You could easily have only Aptio < 5 and Insyde... or have an Aptio 5 and still not understand stuff?

 

"I just know that the problem is moving runtime modules after they have already been moved into SMM."

Erm, what? No clue what you mean, nothing *related to this issue* breaks after it "has been moved into SMM".

 

"I don't see any certainty here from you, you've contradicted yourself multiple times and even agreed that I am indeed correct that the problem is relocation of runtime modules that have been moved to SMM."

I have never once contradicted myself, the issue is I am replying to two definitions of "SMM Driver", which is rubbish. Give me statements using proper words for the outer conditions and I can reply properly. If you cut "that have been moved to SMM" from the latter sentence, it's correct (thought that once again shows you do not seem to understand the issue), though wildly generic. You are literally back to saying "RT_code gets relocated"... cool, thx.

 

"Ummmmmm.... Yeah not seeing what you mean there besides me just not thinking for a second then immediately correcting myself....."

"For a second" - "immediately"... right.

 

"There's only one reason you don't want a conversation about this, because you know damn well that I'm right."

Are you getting dense, I've easily wasted 30 minutes replying, got back out of bed to do so and even bother today. Who are you replying to?

 

"The problem I have here is that DF knows damn well I told him this exact issue almost two months ago."

You noted an open-source, known-for-years behavior of AptioFix. No, you did not "tell me about this exact issue two months ago", even now you can't pin down the issue and are constantly switching opinion on where it is now. DXE or SMM? Why? Make up your mind... and if you sit tight on your narrative, bring it into any connection with your rants.

 

"Then he comes on here with no code or proof of concept basically just saying what I said and that he discovered the issue"

rofl, give me a break. "The issue is that NvramSmm uses a Runtime DXE protocol, which is relocated at bootloader stage" is equal to "RT_code is moved", I see. Not sure if your realize this, but the issue is an actual security issue and the praxis causing it should never ever be applied anywhere.

 

"then says I have no proof"

I am not saying you "have no proof", I am saying your correct statements are generic / known for years and all your others are unrelated to this issue.

 

"I think that DFs approval is not needed, or anyone's but my own for that matter...."

I don't need yours and you don't need mine. You were the one chosing to make this "personal matter" public, so expect some pissedness. That you didn't even think about "Hey, I'm gonna PM DF and just ask why he didn't credit me" shows your real intention, especially as the post was not even a big fuss (note that this is not implying I'm backing off of your rants not contributing anything significant).

 

"Don't let me and DF seem like we are fighting or adversarial. lol, we are not. We just like to argue with each other, HAHA!"

I learned to hate arguing with you, because there literally is no point.

 

Now, finally pin down the exact issue and explain it. Where is it? Why does it happen? How was this obvious from your posts?

And if you cannot go any farther into the issue than "muh RT_code is moved", explain where the significance of sharing this openly visible behavior is.

If you had contacted me privately with a good intention, I probably would have grabbed the permission to share chat logs and do so... There is more than plenty.

If you want proofs that this actually works, maybe ReddestDream will help you... I do not have the hardware.

[apianti]

Let's just the this over with...

 

"I think this is exactly where it belongs. You want it in private for the obvious reason."

Like keeping this {censored} thread uncluttered? I offered IRC, which just seems to be a too small of a stage for you, eh?

 

No, it seems to be perfectly fine of a place. Seems that you are just angry because you got caught, the real reason you do't want this conversation to be here, where other's can see it's record.

 

"Really so you have a working solution to everyone who has non-working NVRAM? Because I'm pretty sure that I do. What's your method? Because the method I've been working on since I brought that up before and have been rewriting v3 is that I make all RT_Data and RT_Code regions into MMIO regions, then I make copies of the RT_Code region and that is relocated. The original is still there in physical memory and the kernel is happy it got the relocated virtual code. But this is hypothetical right???"

Yikes, you accidentially solved the global vars problem , more below...

As to your solution: I am not sure at this point if you don't understand or are just totally incapable of describing the issue. Yes, the solution is just fine, just that I would have the original code reloc'd for the sake of not having to update gRT pointers... in fact that would have been exactly what you would have seen if you downloaded the zip I shared (but removed for bugs) a couple of posts before.

And no, I don't have a solution for everyone, currently I have the choise between writing to read-only data or executing read-write data. A kernel patch that maps all EFI regions as read-write-execute makes it work perfectly fine.

 

You literally said

 

Yes, a fix will be coming to AptioFix after figuring an issue with RT_code relocation. A fix I expect to be working will be tested soon... if it is successful, I will share it here for further validation.

EDIT: File deleted due to a bug...

 

When was I supposed to download this fix that worked? And I know I solved it, not accidentally, over two months of research and trying to solve the problem. When I was talking about relocating the region, it doesn't matter which one you relocate, the copy or the original. You'll have to change stuff in the one that is moved no matter what, it will need rebased or it will not get correct virtual addresses since there can't be two entries for the same memory region... Or at least I've never tried to make one and seems like it probably won't work. I also like how you stating nothing of any idea for how to solve this, but magically after I said what I was doing, THAT's exactly what you did but with no proof cause it got deleted.... 

 

The issue is you throw around with "SMM Driver" without knowing what it means. All drivers inside SMRAM are SMM drivers. No driver outside of SMRAM is a SMM Driver. Drivers communicating with SMM by manually issuing a SMI are *NOT* SMM drivers. If you replace "SMM driver" in *some* spots of what you said, it starts to make at least some sense.

 

Aptio IV used EDK which had no concept of a standalone SMM driver, from 018s/Core/EM/NVRAM/NVRAMDXE.c line 5096:

// Description:	This function is the entry point for this DXE. This function
//				installs NvRam services in and outside SMM.

Hmmmmm.... Also you can't really communicate with a SMM driver without a DXE driver to do so. If you read the spec, SMM drivers are DXE drivers:

The SMM handlers should be stored in firmware files as DXE drivers. The entry point behavior of the driver will distinguish these drivers from other boot service DXE and runtime drivers.

So the driver must be loaded as a DXE driver first before it can say that it is an SMM driver and load ANY module into SMM, doesn't have to be itself. There's also this, from EFI_SMM_BASE_PROTOCOL->Register:

If the input handler is LegacyIA32Binary, the only interesting argument is SourceBuffer, which is simply a pointer to a 16-bit binary image handler. The SMM infrastructure code needs to maintain a list of 16-bit real-mode handlers that can exist only in the SMRAM locations below 1 MB such as the A- and B-segments. The handlers will be 16-bit code that expects to run in big-real mode or to have 32-bit pointer accessibility. The SMM infrastructure code should maintain an array of these 16-bit handlers that are dispatched before going into protected mode and dispatching the list of native-mode, PE32+ handlers. The 16-bit code can be relocated to any 16-byte boundary by way of fixing of the Code Segment (CS) register before invoking each handler.

So, no, SMM drivers do not only reside in SMRAM.

 

"Because I'm talking about the SMM runtime drivers that are not in SMRAM but interact with SMM. That's where the problem lies, when those modules are moved. There are physical addresses inside that pointed to where the region was previously (if you look it's at the leaked code it's a structure which means it's accessed by dereference like a pointer), and those point to buffers that were allocated for SMM."

I saw this later, so I already read other stuff of the post in detail. Can you please finally decide where the issue is now? Is it in the DXE Runtime driver that communicates with the SMM Driver, or is it in the SMM driver itself? If your answer is former, rubbish, not. the. issue.

 

SMM drivers are DXE drivers. And I'm obviously talking about the DXE driver that communicates with the SMM handler it installs which MAY be another driver, but it may not. Wow you really should read the spec if you are calling what actually happens rubbish. Or just look at EFI_SMM_BASE_PROTOCOL and see that you would need to be in a DXE driver already to be able to use it, using it from within itself really does nothing since you need to invoke an SMI to get to the code that was registered into SMRAM.

 

"EDIT2: Also the protocol you refer to as what is causing the problems, the flash protocol, is also used in Aptio IV during NVRAM SMM communication."

Not "also", that is precisely what is the problem lol.

 

That's weird because if it's used in Aptio IV as well, then it would be causing the same issue and I don't have a NVRAM issue but somehow I do?

 

"EDIT3: The NVRAM driver is also only partially in SMM. The driver starts in DXE and installs only the variable store in SMM. I see several variables that could be corrupted by relocation depending on how they may be used later."

Not sure what you mean, cannot comment, not the issue.

 

You should look at the NVRAM code for Aptio IV. Or just look above where the comment about how it enters in DXE and registers an SMM handler.

 

"This sentence just doesn't even make sense. I don't know if you miswrote that or what but.... What? You are the one that said that, and then I was asking how could any variables ever be written then if it is write protected? I don't even know what you mean those from C. You mean the physical addresses I was referring to that are now no longer valid because they were moved? Because I think that's what you mean...."

I had the impression that you were swapping "C global variable" and "NVRAM variable" for my statement, but I guess you did not... You probably solved this accidentially.

Go ahead, mark all RT_code entries as MMIO to protect them from reloc and on kernel entry, change them right back to RT_code and enjoy the GPFs for writing to read-only memory.

After that, you may enjoy the show: https://github.com/practicalswift/osx/blob/master/src/xnu/osfmk/i386/AT386/model_dep.c#L643

If you ask now, where the writes go... Good question, not sure. Could imagine they go into your MMIO region, but I am not certain. They don't go where you thought they go either way.

 

I didn't solve this accidentally. I actively researched how to solve it, and guess what maybe I actually know how to solve the problem? Who would have guessed that? When I brought up the issue two months ago.... I'm only worried about leaving the originals there as MMIO to protect the physical addressed buffers that aren't translated with convert pointer because they are used to communicate with SMM in physical mode. I know exactly where they will go. The virtually converted addresses will point into the RT_Code relocated into the kernel. The physical addresses are still cool and safe in that MMIO to be used when needed, no GPF. So anytime a virtual address is used it uses the kernel like the kernel expects and whenever it needs to communicate with an SMM handler the buffers are all still safely there in MMIO.

 

"You must be in real mode in order to invoke an SMI"

No, you end up in Real Mode *after* issuing a SMI.

 

You end up in SMM. Are you joking? Also the code to invoke the SMI in Aptio IV does go to real mode before invoking the SMI. Don't know if it's necessary or not though....

 

"And in order to enter it you need to write to stuff that was set up and is probably no longer there because it was moved."

So, I am certain again, you don't understand the issue. Nothing was moved out of the DXE Driver's reach and there is no issue entering SMM. I would love to say now that for Runtime DXE Drivers, all addresses are correct at all times, and while they probably are strictly speaking, there still is this impact on global variables...

 

I meant that the buffer that is needed to communicate with SMM is now no longer correctly addressed in some way. As in the physical address of something is no longer in the same place. Say whatever you like but that won't make it true, why do you think the RT_Data regions got protected? Because of physical addresses being moved from where they are pointed at.

 

"I was just saying that only one module interacts with SMI, not that is what is the problem."

What now? Can it reach SMM or not?

 

It's the SMM base protocol, you know exactly what I mean. I sure hope it can, but that doesn't mean when you pass the communication buffer into it that has a physical address it is going to point to where the buffer actually is, so it is possible it does not reach SMM. Remember all these buffers had to be allocated during boot time and still be valid for runtime.

 

"The problem is the relocation of an region that was moved that deals with SMM, which is a lot of RT_Code."

Define "deals with SMM". If you mean any specifically SMM-related code, no, not the issue.

 

The DXE SMM drivers that communicate through buffers with the SMM drivers in SMRAM. If these DXE drivers are moved they now have invalid physical addresses pointing inside themselves. As you said the C variables, which if you try to access this address and there is no mapped (or imporperly attributed) region it is a GPF.

 

"I have multiple computers, so I don't know why you think I don't know what different firmwares are like...."

You could easily have only Aptio < 5 and Insyde... or have an Aptio 5 and still not understand stuff?

 

I have both Aptio IV and Aptio V firmwares. The problem is not me not understanding........

 

"I just know that the problem is moving runtime modules after they have already been moved into SMM."

Erm, what? No clue what you mean, nothing *related to this issue* breaks after it "has been moved into SMM".

 

Ok, so you think that in no way that these two modules need to communicate back in forth between the firewall of SMM? If one of them is registered into SMRAM then either one or both have addresses that no longer point to the same locations after the RT_Code is moved. And since the RT_Code is obviously being moved, I'm guessing that the SMM driver inside of SMRAM has a reference to code in that region. Is that more precise for you? Since you already know the issue but seem to want to be a jerk about it.

 

"I don't see any certainty here from you, you've contradicted yourself multiple times and even agreed that I am indeed correct that the problem is relocation of runtime modules that have been moved to SMM."

I have never once contradicted myself, the issue is I am replying to two definitions of "SMM Driver", which is rubbish. Give me statements using proper words for the outer conditions and I can reply properly. If you cut "that have been moved to SMM" from the latter sentence, it's correct (thought that once again shows you do not seem to understand the issue), though wildly generic. You are literally back to saying "RT_code gets relocated"... cool, thx.

 

I think you need a better grasp on English, it is perfectly ok to omit words because of context. From the context of what I'm saying you should be able to infer what I'm talking about but I will be more precise with exact terms then, if that will help. I mean moved to SMM as in a DXE driver registered a handler into SMM, I don't know how else I could say that because that's what happens... Clearly the underlying problem is the relocation of the runtime areas, since neither linux nor windows do this and obviously have working NVRAM. macOS relocates these regions and magically NVRAM is broken, I actually wouldn't be surprised if almost everything that uses SMM is broken just that NVRAM is probably really the only thing being used at runtime. Also I don't understand but somehow I managed to walk backward into a solution by accident? 

 

"Ummmmmm.... Yeah not seeing what you mean there besides me just not thinking for a second then immediately correcting myself....."

"For a second" - "immediately"... right.

 

"There's only one reason you don't want a conversation about this, because you know damn well that I'm right."

Are you getting dense, I've easily wasted 30 minutes replying, got back out of bed to do so and even bother today. Who are you replying to?

 

...............Yeah...............

 

"The problem I have here is that DF knows damn well I told him this exact issue almost two months ago."

You noted an open-source, known-for-years behavior of AptioFix. No, you did not "tell me about this exact issue two months ago", even now you can't pin down the issue and are constantly switching opinion on where it is now. DXE or SMM? Why? Make up your mind... and if you sit tight on your narrative, bring it into any connection with your rants.

 

I think I've been pretty clear. But it's impossible to convince a blind man he's in the sun if he can't feel it on his skin. Oh, the first post where I linked exactly how I described the relocation issue.... But yeah.... I'm switching all over the place from.... My one position.

 

http://www.insanelymac.com/forum/topic/317802-efi-variable-store-on-aptio-v-haswell-e-and-up/page-6?do=findComment&comment=2561231

 

 

"Then he comes on here with no code or proof of concept basically just saying what I said and that he discovered the issue"

rofl, give me a break. "The issue is that NvramSmm uses a Runtime DXE protocol, which is relocated at bootloader stage" is equal to "RT_code is moved", I see. Not sure if your realize this, but the issue is an actual security issue and the praxis causing it should never ever be applied anywhere.

 

Yeah, that is exactly an equivalency. What are you talking about. Do you think that that runtime DXE is not RT_Code? Is that not what's being relocated? So now this is a security issue? But that doesn't affect any windows or linux OS?

 

"then says I have no proof"

I am not saying you "have no proof", I am saying your correct statements are generic / known for years and all your others are unrelated to this issue.

 

Except I just so happened to accidentally solve it though, right? So you could come in and go, oh, yeah that's the solution! No idea what the problem was or what it was to do with but just magically in only a few posts solved a complex problem by accident...

 

"I think that DFs approval is not needed, or anyone's but my own for that matter...."

I don't need yours and you don't need mine. You were the one chosing to make this "personal matter" public, so expect some pissedness. That you didn't even think about "Hey, I'm gonna PM DF and just ask why he didn't credit me" shows your real intention, especially as the post was not even a big fuss (note that this is not implying I'm backing off of your rants not contributing anything significant).

 

I could have done that but then there would be no conversation. Especially since you didn't post anything other than that it was solved. I don't care about credit at all, already said that. I was just pointing out that I already told you about it and was working on a solution. You have a bad attitude.

 

"Don't let me and DF seem like we are fighting or adversarial. lol, we are not. We just like to argue with each other, HAHA!"

I learned to hate arguing with you, because there literally is no point.

 

So don't talk to me then? I thought we were friends but very obvious to me now that you a not a very good person. And you probably don't like it because you are often wrong. lol.

 

Now, finally pin down the exact issue and explain it. Where is it? Why does it happen? How was this obvious from your posts?

And if you cannot go any farther into the issue than "muh RT_code is moved", explain where the significance of sharing this openly visible behavior is.

If you had contacted me privately with a good intention, I probably would have grabbed the permission to share chat logs and do so... There is more than plenty.

If you want proofs that this actually works, maybe ReddestDream will help you... I do not have the hardware.

 

I have already explained it multiple times you just ignore it and make some strawman argument. If it doesn't work for everyone then it's not the solution. And I have no reason to go out of my way to go other places to say something just so you don't look like an ignorant jerk.

[mhaeuser]

Soon we have wasted more time than research and development costed so far and will reach a maximum character limit for posts or some {censored}... hope you're still enjoying the show.

 

"No, it seems to be perfectly fine of a place. Seems that you are just angry because you got caught, the real reason you do't want this conversation to be here, where other's can see it's record."

If you busted me in private, nobody is here to prevent you from making it public afterwards. Don't talk {censored}, you want attention and appreciation, nothing else.

 

"You literally said [...]"

Yes, that was before we ran into the GPF and vit figured out its cause... I expected to have made a mistake in the protection code, but I did not.

 

"When was I supposed to download this fix that worked?"

Like after you replied another two times before I took it down... or simply trust me that the bin is not some black magic?

 

"And I know I solved it, not accidentally, over two months of research and trying to solve the problem."

I was talking about the global variable writing problem. If you want to tell me you did that by research, I'm afraid you first have to revoke your statement that global variable write not working when protection RT_code from relocation is the most stupid thing I could have said... just a suggestion.

EDIT: Test results have been interpreted based on a wrong premise.

 

"I also like how you stating nothing of any idea for how to solve this, but magically after I said what I was doing, THAT's exactly what you did but with no proof cause it got deleted...."

Ask ReddestDream, ask vit9696, or even join CorpNewt's Discord server... all of them three should have earlier revisions of the fix with patches included. This once more proofs you are not acting well-intended.

 

"Aptio IV used EDK which had no concept of a standalone SMM driver, from 018s/Core/EM/NVRAM/NVRAMDXE.c line 5096:"

Nobody talked about "Standalone" SMM drivers. The difference between a Standalone and a "normal" SMM driver is NOT that one is in SMRAM and one is not, but that Standalone SMM drivers are 100% isolated from DXE. If AMI did use Standalone SMM drivers, there would be no issue.

 

"Hmmmmm.... Also you can't really communicate with a SMM driver without a DXE driver to do so. If you read the spec, SMM drivers are DXE drivers:"

Are you kidding me... (SMM Driver == DXE Driver) != (DXE Driver == SMM Driver). Non sequitur. SMM Drivers are the subset of DXE drivers that are loaded into SMRAM and execute in SMM, end of story. So, when I talk about "`DXE Drivers", it either does not matter whether it is normal RT or SMM, or if it matters, it is not SMM. Because when talking about this kind of issue, distinguishing between the two types is essential and you plainly did not properly do that. No driver outside of SMRAM is a SMM driver, accept it.

 

"There's also this, from EFI_SMM_BASE_PROTOCOL->Register"
SmmBase was a catastrophic Intel Framework concept. It was deprecated by UEFI's SmmBase2 ages ago, which has no [EDIT: such] Register function. How does this work, according to you?

In modern firmware, SMM drivers are not registered from within DXE, but they are loaded by the SMM Core, directly into SMRAM.

 

"SMM drivers are DXE drivers. And I'm obviously talking about the DXE driver that communicates with the SMM handler it installs which MAY be another driver, but it may not. Wow you really should read the spec if you are calling what actually happens rubbish."

This has nothing to do with the spec. RT relocation is a proprietary Apple concept and calling DXE code from within SMM is... heavily discouraged.

 

"Or just look at EFI_SMM_BASE_PROTOCOL and see that you would need to be in a DXE driver already to be able to use it, using it from within itself really does nothing since you need to invoke an SMI to get to the code that was registered into SMRAM."

Who said that only SMM drivers can communicate with SMM drivers? What is "rubbish" is the statement that this is what is causing the issue. SmmBase2 is called just fine, don't worry.

 

"That's weird because if it's used in Aptio IV as well, then it would be causing the same issue and I don't have a NVRAM issue but somehow I do?"

Yes. If.

 

"So anytime a virtual address is used it uses the kernel like the kernel expects and whenever it needs to communicate with an SMM handler the buffers are all still safely there in MMIO."

Correct. What was that again about the "global variables write causing GPF" being rubbish when RT_Code stays in place?

EDIT: Test results have been interpreted based on a wrong premise.

 

"You end up in SMM. Are you joking?"

*Sigh*, SMM is a privilege mode and not an addressing mode.

SmiEntry - real mode: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm#L55

SmiEntry - protected mode: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm#L81

Is EDK2 Fake News now?

 

"Also the code to invoke the SMI in Aptio IV does go to real mode before invoking the SMI."

Maybe it's actually both... I expected the SMI to take care of that.

 

"I meant that the buffer that is needed to communicate with SMM is now no longer correctly addressed in some way."

That was the Aptio IV issue and is not the Aptio V issue.

 

"I meant that the buffer that is needed to communicate with SMM is now no longer correctly addressed in some way. As in the physical address of something is no longer in the same place. Say whatever you like but that won't make it true, why do you think the RT_Data regions got protected? Because of physical addresses being moved from where they are pointed at."

I really have to think more about how to reply... Nothing was moved out of the DXE Driver's reach. The DXE Driver's. The Communication Buffer cannot be moved out of its reach because DXE code uses virtual addresses, which as of today's AF, are always valid. Something was moved out of the SMM Driver's reach, it can never be vice-versa (if the code works...).

 

"It's the SMM base protocol, you know exactly what I mean."

I know what you mean by the protocol... and it is not the issue.

 

"I sure hope it can, but that doesn't mean when you pass the communication buffer into it that has a physical address it is going to point to where the buffer actually is"

Yes, it does mean it, because RT_data is not moved. It made sense if the CommBuffer was RT_code, which it is not.

 

"If these DXE drivers are moved they now have invalid physical addresses pointing inside themselves."

There it sounds a little bit like what I said above, that you think the CommBuffer resides in RT_code... no, it does not as per code and tests.

 

"The problem is not me not understanding........"

lolz

 

"Ok, so you think that in no way that these two modules need to communicate back in forth between the firewall of SMM?"

No, I am saying that no module is "moved". Data is moved. And the move is fine.

 

"I'm guessing that the SMM driver inside of SMRAM has a reference to code in that region."

Guessing here, guessing there, I thought you solved it?

 

"Is that more precise for you? Since you already know the issue but seem to want to be a jerk about it."

I was not certain you meant it that way, but you seem to do, and it is plainly wrong.

 

"I mean moved to SMM as in a DXE driver registered a handler into SMM, I don't know how else I could say that because that's what happens..."

Not for ages... You won't find SmmBase in any recent Aptio V firmware. Look for SmmBase2 - and for it's register function.

 

"Clearly the underlying problem is the relocation of the runtime areas, since neither linux nor windows do this and obviously have working NVRAM."

True, that is the problem. But you don't understand the exact issue. You don't understand which essential piece is moved and why precisely it breaks... I do and I explained it.

 

"Yeah, that is exactly an equivalency."

You have been talking about explicitely SMM-related components such as the communication buffer and the SmmBase protocol being screwed. They are not. If these terms were equivalent, I suppose you would understand the problem. "RT_code is moved" is such a valuable statement that it is required to be mentioned? Alright, then thanks once more (I already did on POSX four years ago) to night199uk for predicting the issue and dmazar for implementing the fix.

 

"Except I just so happened to accidentally solve it though, right?"

You solved it? FIne, post the fix. Guess I don't need to anymore.

 

"I could have done that but then there would be no conversation. Especially since you didn't post anything other than that it was solved."

I could have... sent you... what I have? No? kk.

 

"So don't talk to me then?"

I would have stopped responding if this happened in private (though if you were well-intended acting, it would have not come this far), but I kinda need to keep replying till you stop spreading {censored} that I take credit over your stuff.

 

"I was just pointing out that I already told you about it and was working on a solution. You have a bad attitude."

Why does it matter if you were already working on a solution? I don't see any. And I don't think it mattered when I was close to the FV2 solution and instead of attracting people to give me some support, you encouraged Andy Vand to write a hacky mess that manually decrypts the volume... and never happened. But I mildly remember you saying "Oh, I said that xxx decades ago" too when I figured out FV2. Yeah, bite me.

 

"I thought we were friends but very obvious to me now that you a not a very good person."

Ugh, I thought so in 2014, before you randomly abandoned the ship (for whatever reasons, I don't care now)... you know, when I was euphoric about your promises for Clover v3, spread it everywhere and tried to achieve the skills to contribute.

I thought we were still coming along well, before you joined IRC several times talking stuff, me correcting you, you spammed how I was wrong and don't understand stuff and left without any resolution. Every single time, just in the fashion as this goes for several hours now. Yes, one time I had an achievement, when you were not thinking straight "for a second" and insulted me over it. Will I have another?

 

I let people perform tests. When you literally restore the page the AMI Flash protocol resides in to its original location (as it's used in SMM code), it works with the rwx kernel patch. Test it yourself...

[apianti]

Soon we have wasted more time than research and development costed so far and will reach a maximum character limit for posts or some {censored}... hope you're still enjoying the show.

 

"No, it seems to be perfectly fine of a place. Seems that you are just angry because you got caught, the real reason you do't want this conversation to be here, where other's can see it's record."

If you busted me in private, nobody is here to prevent you from making it public afterwards. Don't talk {censored}, you want attention and appreciation, nothing else.

 

"You literally said [...]"

Yes, that was before we ran into the GPF and vit figured out its cause... I expected to have made a mistake in the protection code, but I did not.

 

I really don't care DF. I want to solve the problem. That's all I've ever wanted, so stop. You keep personally attacking me which of course I'm not going to allow. I don't even understand how you could have solved it then, and chosen your post as the answer if you didn't even have the solution yet.... You deleted the file so obviously there's some problem with it. And my solution works for all runtime not just when one protocol is used. There's no need to restore something that is still there. Problem is it's tied to v3, I'm sure AptioFix could easily be modified though.

 

"When was I supposed to download this fix that worked?"

Like after you replied another two times before I took it down... or simply trust me that the bin is not some black magic?

 

I didn't even see it until you pointed out that it wasn't even there anymore, because it wasn't in the original post.

 

"And I know I solved it, not accidentally, over two months of research and trying to solve the problem."

I was talking about the global variable writing problem. If you want to tell me you did that by research, I'm afraid you first have to revoke your statement that global variable write not working when protection RT_code from relocation is the most stupid thing I could have said... just a suggestion.

 

Because you didn't use the word relocated, so I thought you were saying something really stupid, lol. Of course if they are relocated into the kernel then they are write protected as code. You said

 

 

Global variables reside in which memory? And this memory has which attributes? Spoiler: RT_code, which has read and execute, but not write.

I thought you meant that RT_Code regions do not have write access. Because the problem isn't even anything to do with the narrow scope you are giving it, with just the flash protocol/global variable thing. It's all runtime. This is happening to every runtime module that also has an SMM handler, just what are the side effects of the rest failing? We know NVRAM stops working. Saying you said something stupid doesn't mean I said you're stupid.

 

"I also like how you stating nothing of any idea for how to solve this, but magically after I said what I was doing, THAT's exactly what you did but with no proof cause it got deleted...."

Ask ReddestDream, ask vit9696, or even join CorpNewt's Discord server... all of them three should have earlier revisions of the fix with patches included. This once more proofs you are not acting well-intended.

 

But that took place more than two months ago? I doubt that very much DF. I should have been included is more where my feelings lay. I think that you too narrowly scoped the solution.

 

"Aptio IV used EDK which had no concept of a standalone SMM driver, from 018s/Core/EM/NVRAM/NVRAMDXE.c line 5096:"

Nobody talked about "Standalone" SMM drivers. The difference between a Standalone and a "normal" SMM driver is NOT that one is in SMRAM and one is not, but that Standalone SMM drivers are 100% isolated from DXE. If AMI did use Standalone SMM drivers, there would be no issue.

 

Standalone as in a DXE driver that is registered only as an SMM handler. Aptio IV has a terrible crude method of trying to implement this behavior though, it uses a few mostly security handlers. The NVRAM is not standalone. Aptio V does use stand alone which is what the problem is, instead of just the variable store in SMRAM the entire SMM handler is the NVRAM module. How can you update the NVRAM flash chip without flashing it? There is no way to completely isolate something in SMRAM unless you just want to lose it, why would you want to do that?

 

"Hmmmmm.... Also you can't really communicate with a SMM driver without a DXE driver to do so. If you read the spec, SMM drivers are DXE drivers:"

Are you kidding me... (SMM Driver == DXE Driver) != (DXE Driver == SMM Driver). Non sequitur. SMM Drivers are the subset of DXE drivers that are loaded into SMRAM and execute in SMM, end of story. So, when I talk about "`DXE Drivers", it either does not matter whether it is normal RT or SMM, or if it matters, it is not SMM. Because when talking about this kind of issue, distinguishing between the two types is essential and you plainly did not properly do that. No driver outside of SMRAM is a SMM driver, accept it.

 

Actually SMM driver == DXE driver, but never said anything about the other way around. But there is literally no such thing as an SMM driver. It is a DXE driver that is registered as an SMM handler.  We are both using them loosely as terms for specific instances of a driver and I'm pretty sure you know exactly too. Once again, there is no need to get so precise with english it's more about context. On a side note here, remember when I was telling you in chat about having to force all allocations below 4GB, that's because SMM only uses 32bit addressing.

 

"There's also this, from EFI_SMM_BASE_PROTOCOL->Register"

SmmBase was a catastrophic Intel Framework concept. It was deprecated by UEFI's SmmBase2 ages ago, which has no [EDIT: such] Register function. How does this work, according to you?

In modern firmware, SMM drivers are not registered from within DXE, but they are loaded by the SMM Core, directly into SMRAM.

 

lol, EFI_SMM_BASE2_PROTOCOL is also deprecated. I understand that they are loaded directly from the FV into SMRAM, actually they are temporarily in regular memory. I said above about how Aptio IV is EDK based and tried to emulate this behavior crudely, except the NVRAM module is not part of that.

 

"SMM drivers are DXE drivers. And I'm obviously talking about the DXE driver that communicates with the SMM handler it installs which MAY be another driver, but it may not. Wow you really should read the spec if you are calling what actually happens rubbish."

This has nothing to do with the spec. RT relocation is a proprietary Apple concept and calling DXE code from within SMM is... heavily discouraged.

 

That is not boot code though so what do you mean? The flash protocol is runtime and the spec says that you can't make any DXE (boot) calls after the SMM entry point, but can always make runtime calls. And once again referring to the fact that there are two separate DXE drivers here, one that is an actual DXE driver that communicates with another DXE driver that is in SMRAM that actually does the stuff. Is that what you are having trouble with? That there are two DXE drivers in order for whatever is being done with SMM to work? I would say moving the memory regions would be much more discouraged.....

 

"Or just look at EFI_SMM_BASE_PROTOCOL and see that you would need to be in a DXE driver already to be able to use it, using it from within itself really does nothing since you need to invoke an SMI to get to the code that was registered into SMRAM."

Who said that only SMM drivers can communicate with SMM drivers? What is "rubbish" is the statement that this is what is causing the issue. SmmBase2 is called just fine, don't worry.

 

Loading into SMRAM, you aren't loading into SMRAM from SMRAM is what I meant. Starting to get tired of having to explain mundane details of you misunderstanding me.

 

"That's weird because if it's used in Aptio IV as well, then it would be causing the same issue and I don't have a NVRAM issue but somehow I do?"

Yes. If.

 

Then yes, because I have the code and can see that it uses the flash protocol in SMRAM to update the NVRAM during runtime. But it is not affecting it, because the flash protocol is stored outside of the SMM handler pointer converted for runtime. The SMM handler that was loaded directly as a module from FV does not do this conversion, the RT_Code is moved that has the flash protocol. SMM handler now has dangling pointer.

 

"You end up in SMM. Are you joking?"

*Sigh*, SMM is a privilege mode and not an addressing mode.

SmiEntry - real mode: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm#L55

SmiEntry - protected mode: https://github.com/tianocore/edk2/blob/master/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm#L81

Is EDK2 Fake News now?

 

Yeah, so I'm not sure what you are getting at. I was saying that it ends up in SMM, not in real mode. You said it ended up in real mode.... Huh?

 

"Also the code to invoke the SMI in Aptio IV does go to real mode before invoking the SMI."

Maybe it's actually both... I expected the SMI to take care of that.

 

I would too that's why I said it, but then crossed it out, and wrote not 100% until I got a chance to look. Still not 100% though but every example I see does thunk to real mode first.

 

"I meant that the buffer that is needed to communicate with SMM is now no longer correctly addressed in some way."

That was the Aptio IV issue and is not the Aptio V issue.

 

It was a different kind of dangling pointer but it is essentially the same sort of issue. Mostly in reverse, it seems.

 

"I meant that the buffer that is needed to communicate with SMM is now no longer correctly addressed in some way. As in the physical address of something is no longer in the same place. Say whatever you like but that won't make it true, why do you think the RT_Data regions got protected? Because of physical addresses being moved from where they are pointed at."

I really have to think more about how to reply... Nothing was moved out of the DXE Driver's reach. The DXE Driver's. The Communication Buffer cannot be moved out of its reach because DXE code uses virtual addresses, which as of today's AF, are always valid. Something was moved out of the SMM Driver's reach, it can never be vice-versa (if the code works...).

 

Yes that is what I meant but it's still some buffer/pointer/something that's not there anymore. The vice versa is actually the Aptio IV problem, haha.

 

"It's the SMM base protocol, you know exactly what I mean."

I know what you mean by the protocol... and it is not the issue.

 

Never said it was, I think I actually said, that's not the issue. I forget what my point there was.....

 

"I sure hope it can, but that doesn't mean when you pass the communication buffer into it that has a physical address it is going to point to where the buffer actually is"

Yes, it does mean it, because RT_data is not moved. It made sense if the CommBuffer was RT_code, which it is not.

 

Referring to the SMM handler. If you pass in a physical address inside of the buffer, not the buffer itself, that has been moved. It's just another scenario of a dangling pointer.

 

"If these DXE drivers are moved they now have invalid physical addresses pointing inside themselves."

There it sounds a little bit like what I said above, that you think the CommBuffer resides in RT_code... no, it does not as per code and tests.

 

No, I just used the word they wrongly in place for SMM handlers. And it does sound wrong.

 

EDIT: I meant outside themselves, not inside....

 

"Ok, so you think that in no way that these two modules need to communicate back in forth between the firewall of SMM?"

No, I am saying that no module is "moved". Data is moved. And the move is fine.

 

Ah that's a moot point, we both know that's how it's communicating that's not the point. You understand that there is communication between two separate codes right? I can't seem to get if you are not getting that, and that is why I can't seem to get my point across. Plus I'm trying to type an essay while doing a ton of other stuff haha.

 

 

"I'm guessing that the SMM driver inside of SMRAM has a reference to code in that region."

Guessing here, guessing there, I thought you solved it?

 

That is a figure of speech. As in sarcasm because you know that's what the problem is.

 

"I mean moved to SMM as in a DXE driver registered a handler into SMM, I don't know how else I could say that because that's what happens..."

Not for ages... You won't find SmmBase in any recent Aptio V firmware. Look for SmmBase2 - and for it's register function.

 

Oh man, I was talking about look at how the register function works and looking at the Aptio IV crude way of implementing SmmCore. I know that now the drivers are loaded directly from FV by a DXE driver in firmwares that follow at least PI 1.2 spec. To prevent something malicious from loading into SMRAM. But they are still loaded the same way. And they still have a counterpart outside of SMRAM to communicate with.

 

"Clearly the underlying problem is the relocation of the runtime areas, since neither linux nor windows do this and obviously have working NVRAM."

True, that is the problem. But you don't understand the exact issue. You don't understand which essential piece is moved and why precisely it breaks... I do and I explained it.

 

That is only one firmware though. Did the fix work for you? And I do understand why it's failing just not so narrowly scoped to one piece. It's the entire mechanism of relocating that breaks SMM handlers.

 

"Yeah, that is exactly an equivalency."

You have been talking about explicitely SMM-related components such as the communication buffer and the SmmBase protocol being screwed. They are not. If these terms were equivalent, I suppose you would understand the problem. "RT_code is moved" is such a valuable statement that it is required to be mentioned? Alright, then thanks once more (I already did on POSX four years ago) to night199uk for predicting the issue and dmazar for implementing the fix.

 

I have been trying to make comparisons to other situations that caused dangling pointers to explain to you the problem is broader than your one protocol, in no way have I said that these are related or messed up. Moving the RT_Code breaks SMM handlers that have physical addresses that point into that code region that was moved. And you're referring to RT_Data for Aptio IV communication buffers for SMM.

 

"Except I just so happened to accidentally solve it though, right?"

You solved it? FIne, post the fix. Guess I don't need to anymore.

 

I would have to modify the AptioFix from v2 as mine is for v3 and no way near ready. And I've basically told you exactly what it does. You should be able to make your fix more broadly so it works for everyone.

 

"I could have done that but then there would be no conversation. Especially since you didn't post anything other than that it was solved."

I could have... sent you... what I have? No? kk.

 

Yes you could have, but you didn't instead you acted like I wanted attention or credit when really I wanted to talk about it..... Which is why I said I talked to you about this two months ago.

 

"I was just pointing out that I already told you about it and was working on a solution. You have a bad attitude."

Why does it matter if you were already working on a solution? I don't see any. And I don't think it mattered when I was close to the FV2 solution and instead of attracting people to give me some support, you encouraged Andy Vand to write a hacky mess that manually decrypts the volume... and never happened. But I mildly remember you saying "Oh, I said that xxx decades ago" too when I figured out FV2. Yeah, bite me.

 

Um, no, I actually encouraged both of you. I'm allowed to want many people to succeed and work together. But this is what I mean by bad attitude, I'm just talking and you are taking everything personally and then reflecting that back at me as insults. You don't seem to want to play on a team unless you get to say everything and do everything and take all the credit. No one cares, I just want stuff to work. I'm not a petulant child.

 

"I thought we were friends but very obvious to me now that you a not a very good person."

Ugh, I thought so in 2014, before you randomly abandoned the ship (for whatever reasons, I don't care now)... you know, when I was euphoric about your promises for Clover v3, spread it everywhere and tried to achieve the skills to contribute.

I thought we were still coming along well, before you joined IRC several times talking stuff, me correcting you, you spammed how I was wrong and don't understand stuff and left without any resolution. Every single time, just in the fashion as this goes for several hours now. Yes, one time I had an achievement, when you were not thinking straight "for a second" and insulted me over it. Will I have another?

 

The reason I left is complicated but it's probably similar to why there are many that are not around anymore... That's all that needs to be said. Dude, sometimes I just leave at inopportune times. You definitely should not take anything I say as an insult because I'm not insulting you, I just wouldn't talk to you if I didn't like you. Also sometimes devil's advocate is the best method to determine if something works. And I'm very good at it. You should not take it personally, I do not mean it that way. And I sometimes I'm in a hurry and this big long chat happens, I start getting distracted and just use lazy english. Which obviously is causing problems.

 

I let people perform tests. When you literally restore the page the AMI Flash protocol resides in to its original location (as it's used in SMM code), it works with the rwx kernel patch. Test it yourself...

 

I never said it didn't work. I said that you didn't prove that it worked. And also I was giving you my method which should make it so the kernel patch is not needed, and also doesn't give a vulnerability of being writable runtime. I don't have it?

[mhaeuser]

"You keep personally attacking me which of course I'm not going to allow."

You started off with an accusation, what precisely did you expect?

 

"I'm not going to allow. I don't even understand how you could have solved it then, and chosen your post as the answer if you didn't even have the solution yet...."

I have not found a solution for a sub-problem... either the not-relocated code is marked MMIO, and we get a NX fault, or it is marked RT_code, and we get a write-GPF. This proves that there is something fundamentally wrong with something in the AptioFix-boot.efi-XNU chain. The current code should not work, it should throw with GPFs.  When RT_code is relocated, UEFI gets a Memory Map with "old physical address -> new virtual address" mapping, there is no sane explaination for the drivers writing to their original locations, especially not to the original virtual addresses. That might be the issue you have been refering to for the past day, but it is not in the slightest related to why NVRAM breaks on Aptio V at the end of boot.efi, when memory is moved. It is also an issue, but not this.

 

"You deleted the file so obviously there's some problem with it."

The GPF.

 

"And my solution works for all runtime not just when one protocol is used."

True, but within the entire conversation, you did not once acknowledge the issue as what it is... this issue. Your patch was obviously targeted to fix an issue with the current AptioFix setup, which for reasons unknown to me is broken, and it happened to also fix the issue with the AMI Flash protocol.

 

"Because you didn't use the word relocated, so I thought you were saying something really stupid, lol."

What you interpreted doesn't make sense on any technical level, but yes, could have been more clear. But yeah, if you call me out for describing the issue as talking rubbish and then claiming you fixed it via research, you gotta expect a confused response.

 

"Of course if they are relocated into the kernel then they are write protected as code."

Well, "of course". Precisely this is what should make all current systems blow up. They are written to some other place, for whatever reason. Do you actually know?

 

"But that took place more than two months ago?"

No, but it took place before you introduced your solution here. You really want to go back to these ancient "RT_code is moved" posts again?

 

"I think that you too narrowly scoped the solution."

I scoped it to fix this specific issue. The issue you are refering too is much broader and a proper fix might implicitely fix this, but not necessarily, depending on the approach.

 

"Actually SMM driver == DXE driver, but never said anything about the other way around."

You said that you were refering to the "SMM Runtime drivers outside of SMRAM" or something... that does not exist.

 

"But there is literally no such thing as an SMM driver. It is a DXE driver that is registered as an SMM handler."

I don't know the precise term from the spec now, but it's most obvious what I mean and I defined the term about three times.

 

"We are both using them loosely as terms for specific instances of a driver"

Nope, every driver in SMRAM is a SMM driver and every outside is not, quite clear. Precision is important because only a SMM driver can be broken by the effects of correct boot.efi relocation as both driver types use a different addressing mode.

 

"On a side note here, remember when I was telling you in chat about having to force all allocations below 4GB, that's because SMM only uses 32bit addressing."

Yes, you said that, and I still saw no proof of that... as in being something necessary and universally valid, not something implicite, like maybe a limit in what can be passed as the communication buffer's address.

 

"lol, EFI_SMM_BASE2_PROTOCOL is also deprecated."

But not deprecated in usage, maybe by the spec...

 

"actually they are temporarily in regular memory"

And you say I shouldn't get so precise? They are never executed from normal memory.

 

"And once again referring to the fact that there are two separate DXE drivers here, one that is an actual DXE driver that communicates with another DXE driver that is in SMRAM that actually does the stuff"

No, you still do not understand it. The NVRAM DXE driver fires an SMI to let the NVRAM SMM driver write the variable. However, the NVRAM SMM driver then accesses the Runtime DXE protocol AMI Flash and that is the issue. NvramDxe[normal, DXE] -> NvramSmm[sMM, SMM] -> AmiFlash[sMM, DXE] (Module/Protocol[ExecutionMode, CodeType]). NvramSmm makes a call out of SMM to the non-SMM protocol, which was moved by boot.efi. That is the issue, no CommBuffer, no invalid addresses in the DXE driver, or whatever. DXE->SMM is fine and normal procedure, SMM->DXE is dangerous and discouraged.

 

"Loading into SMRAM, you aren't loading into SMRAM from SMRAM is what I meant. Starting to get tired of having to explain mundane details of you misunderstanding me."

What relevance has the origin have to anything? You could do SMRAM->SMRAM, maybe doesn't make a ton of sense, but it literally does not matter. What does matter is that SMM drivers get loaded into SMRAM and never leave it.

 

"Yeah, so I'm not sure what you are getting at. I was saying that it ends up in SMM, not in real mode. You said it ended up in real mode.... Huh?"

I can call it "SMM real mode" or "SMM 16-bit addressing mode", though there is no official documentation of these names I think.

 

"It was a different kind of dangling pointer but it is essentially the same sort of issue. Mostly in reverse, it seems."

Not really in reverse, I kinda made it seem like it would be somehow opposite, but it's not. From SMM view it's the same "something was moved away", but ofc for different reasons etc.

 

"Referring to the SMM handler. If you pass in a physical address inside of the buffer, not the buffer itself, that has been moved. It's just another scenario of a dangling pointer."

True, but yet again a scenario that is not happening for this issue.

 

"You understand that there is communication between two separate codes right? I can't seem to get if you are not getting that, and that is why I can't seem to get my point across."

Yes, I understand that, this procedure is just fine though.

 

"That is a figure of speech. As in sarcasm because you know that's what the problem is."

Well, yes, the SMM code has a wrong address. The problem is that I'm quite certain you don't understand why it is invalid.

 

"That is only one firmware though. Did the fix work for you?"

It worked for two people... I don't have an Aptio V board.

 

"And I do understand why it's failing just not so narrowly scoped to one piece."

"I have been trying to make comparisons to other situations that caused dangling pointers to explain to you the problem is broader than your one protocol"

Well, there is only one piece that breaks it. The rest is also an issue, but not directly related to this. Indeed, it's an entirely different issue, you just seem to think yours is a "broader version" of the actual one. Both are effects from relocation, but not the same issue.

 

"Yes you could have, but you didn't instead you acted like I wanted attention or credit when really I wanted to talk about it....."

I also always start technical talks with "Uhm, I have said that before you!!!".

 

"Um, no, I actually encouraged both of you. I'm allowed to want many people to succeed and work together. But this is what I mean by bad attitude, I'm just talking and you are taking everything personally and then reflecting that back at me as insults."

Yes, latter may be true because, as you said yourself, you come off as a d i c k. However, your point was that you were working on a fix already... so? That's what I was reacting to.

 

"I never said it didn't work. I said that you didn't prove that it worked. And also I was giving you my method which should make it so the kernel patch is not needed, and also doesn't give a vulnerability of being writable runtime. I don't have it?"

Yes, I didn't proove it works because, how and why should I? Two people tested it and reported success independently, that's enough for me.

 

I see the shift in tone again, same as last time, from "you don't want to look like an ignorant jerk" to "I just wanted to talk"... you seem to get mad at something without realizing it and then cool down as you go, but without taking note of your former anger. This could have been so easy.

[apianti]

"You keep personally attacking me which of course I'm not going to allow."

You started off with an accusation, what precisely did you expect?

 

This is an insult? I don't see how that's the case.... 

Hmmmm.... Didn't I point this out to you in a conversation a while back, like two months ago?

 

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page-765?do=findComment&comment=2530247

http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page-765?do=findComment&comment=2530462

Seems like me trying to get in on the conversation but yeah, you should maybe go back and reread because that is not the case.... You immediately became hostile towards me. But believe whatever you want man.

 

"I'm not going to allow. I don't even understand how you could have solved it then, and chosen your post as the answer if you didn't even have the solution yet...."

I have not found a solution for a sub-problem... either the not-relocated code is marked MMIO, and we get a NX fault, or it is marked RT_code, and we get a write-GPF. This proves that there is something fundamentally wrong with something in the AptioFix-boot.efi-XNU chain. The current code should not work, it should throw with GPFs.  When RT_code is relocated, UEFI gets a Memory Map with "old physical address -> new virtual address" mapping, there is no sane explaination for the drivers writing to their original locations, especially not to the original virtual addresses. That might be the issue you have been refering to for the past day, but it is not in the slightest related to why NVRAM breaks on Aptio V at the end of boot.efi, when memory is moved. It is also an issue, but not this.

 

I am not talking about whatever this at all. I am talking about SMM handlers no longer having a physical address pointer into a RT_Code region because it moved. This causes a GPF because there is nothing there in physical mode. Has nothing to do with Virtual mode.

 

"You deleted the file so obviously there's some problem with it."

The GPF.

 

"And my solution works for all runtime not just when one protocol is used."

True, but within the entire conversation, you did not once acknowledge the issue as what it is... this issue. Your patch was obviously targeted to fix an issue with the current AptioFix setup, which for reasons unknown to me is broken, and it happened to also fix the issue with the AMI Flash protocol.

 

No, it's targeted to fix all of the issues of dangling pointers left in SMM handlers because RT_Code was moved. It is a broader solution that one specific issue you are saying. And it is to fix NVRAM, we were literally talking about the NVRAM problem.....

 

 

 

"Because you didn't use the word relocated, so I thought you were saying something really stupid, lol."

What you interpreted doesn't make sense on any technical level, but yes, could have been more clear. But yeah, if you call me out for describing the issue as talking rubbish and then claiming you fixed it via research, you gotta expect a confused response.

 

Relocated is very important in that sense because otherwise it makes it seem like it's just boot time RT_Code.

 

"Of course if they are relocated into the kernel then they are write protected as code."

Well, "of course". Precisely this is what should make all current systems blow up. They are written to some other place, for whatever reason. Do you actually know?

 

Huh? When the region isn't meant to be moved then yeah that's probably going to have unwanted side effects.

 

"But that took place more than two months ago?"

No, but it took place before you introduced your solution here. You really want to go back to these ancient "RT_code is moved" posts again?

 

Yeah, I mean, there's no such thing as saying hey lets talk more about that because it applies to solving what WE WERE TALKING ABOUT SOLVING THEN.

 

"I think that you too narrowly scoped the solution."

I scoped it to fix this specific issue. The issue you are refering too is much broader and a proper fix might implicitely fix this, but not necessarily, depending on the approach.

 

You are restoring one region, that's only going to help if the only problem is that protocol. But you don't know that's the only problem. My method definitely fixes this problem because it also keeps the original code where it was it just also duplicates and rebases the region to make a duplicate copy that can be relocated in kernel.

 

"Actually SMM driver == DXE driver, but never said anything about the other way around."

You said that you were refering to the "SMM Runtime drivers outside of SMRAM" or something... that does not exist.

 

Referring to the module that interacts with the module in SMRAM.... It does exist. And I clarified it many times.

 

"On a side note here, remember when I was telling you in chat about having to force all allocations below 4GB, that's because SMM only uses 32bit addressing."

Yes, you said that, and I still saw no proof of that... as in being something necessary and universally valid, not something implicite, like maybe a limit in what can be passed as the communication buffer's address.

 

Well if you look the SMI interrupt only ever goes into real mode or 32bit protected mode. You linked it, it's the same in Aptio.

 

"lol, EFI_SMM_BASE2_PROTOCOL is also deprecated."

But not deprecated in usage, maybe by the spec...

 

Yet you missed my point that deprecated does not mean it can't be present and used.

 

"But there is literally no such thing as an SMM driver. It is a DXE driver that is registered as an SMM handler."

I don't know the precise term from the spec now, but it's most obvious what I mean and I defined the term about three times.

 

"We are both using them loosely as terms for specific instances of a driver"

Nope, every driver in SMRAM is a SMM driver and every outside is not, quite clear. Precision is important because only a SMM driver can be broken by the effects of correct boot.efi relocation as both driver types use a different addressing mode.

 

That is a term that is used, there is no such thing as an SMM driver. It is just a DXE driver that registered as an SMM handler. As I said it is a term we are both using to mean something. There is no EFI SMM subsystem to set like it's different than DXE or runtime.

 

"actually they are temporarily in regular memory"

And you say I shouldn't get so precise? They are never executed from normal memory.

 

I never said they were executed I said temporarily in regular memory before being moved to SMRAM. You should get more precise, lol.

 

 

"And once again referring to the fact that there are two separate DXE drivers here, one that is an actual DXE driver that communicates with another DXE driver that is in SMRAM that actually does the stuff"

No, you still do not understand it. The NVRAM DXE driver fires an SMI to let the NVRAM SMM driver write the variable. However, the NVRAM SMM driver then accesses the Runtime DXE protocol AMI Flash and that is the issue. NvramDxe[normal, DXE] -> NvramSmm[sMM, SMM] -> AmiFlash[sMM, DXE] (Module/Protocol[ExecutionMode, CodeType]). NvramSmm makes a call out of SMM to the non-SMM protocol, which was moved by boot.efi. That is the issue, no CommBuffer, no invalid addresses in the DXE driver, or whatever. DXE->SMM is fine and normal procedure, SMM->DXE is dangerous and discouraged.

 

Dude have you read any of my posts or are you purposefully just completely ignoring that I'm telling you I know the problem is dangling points from SMM handlers. I don't know how many more times I could say it. I also gave other examples of dangling pointers, one that also affect SMM handlers is when you pass an address inside the communication buffer that got moved.

 

"Loading into SMRAM, you aren't loading into SMRAM from SMRAM is what I meant. Starting to get tired of having to explain mundane details of you misunderstanding me."

What relevance has the origin have to anything? You could do SMRAM->SMRAM, maybe doesn't make a ton of sense, but it literally does not matter. What does matter is that SMM drivers get loaded into SMRAM and never leave it.

 

Actually you can't because you can only use boot code (loading an image) in the SMM entry point, which would mean that you would kick yourself out of the entry point by invoking another SMI. If it would even allow you. You would just use the SMM table's load image method.

 

"Yeah, so I'm not sure what you are getting at. I was saying that it ends up in SMM, not in real mode. You said it ended up in real mode.... Huh?"

I can call it "SMM real mode" or "SMM 16-bit addressing mode", though there is no official documentation of these names I think.

 

Ok, then why wouldn't you say that. And why even make the comment I was responding to?

 

"That is a figure of speech. As in sarcasm because you know that's what the problem is."

Well, yes, the SMM code has a wrong address. The problem is that I'm quite certain you don't understand why it is invalid.

 

I do. But I'm beginning to think that you either don't or you're purposefully starting to get so condescending that I'm about to not talk to you anymore DF.

 

"Yes you could have, but you didn't instead you acted like I wanted attention or credit when really I wanted to talk about it....."

I also always start technical talks with "Uhm, I have said that before you!!!".

 

Maybe you should scroll up a little because that's not what I said. I am very clearly trying to get into a conversation, and if you think otherwise then dude you have some issues.

 

"Um, no, I actually encouraged both of you. I'm allowed to want many people to succeed and work together. But this is what I mean by bad attitude, I'm just talking and you are taking everything personally and then reflecting that back at me as insults."

Yes, latter may be true because, as you said yourself, you come off as a d i c k. However, your point was that you were working on a fix already... so? That's what I was reacting to.

 

I didn't say I was working on a fix until much later, you were clearly being a {censored} to me by that point like couldn't possibly comprehend because YOU didn't understand my previous messages.

 

"I never said it didn't work. I said that you didn't prove that it worked. And also I was giving you my method which should make it so the kernel patch is not needed, and also doesn't give a vulnerability of being writable runtime. I don't have it?"

Yes, I didn't proove it works because, how and why should I? Two people tested it and reported success independently, that's enough for me.

 

Really because where's the driver, you said it doesn't work? They got to the desktop and wrote NVRAM variables, restarted, and they were still there? Your word is no longer enough proof. Also because you said it doesn't work and removed it.....

 

 

I see the shift in tone again, same as last time, from "you don't want to look like an ignorant jerk" to "I just wanted to talk"... you seem to get mad at something without realizing it and then cool down as you go, but without taking note of your former anger. This could have been so easy.

 

It could have been easy because you could have just starting talking to me about the topic instead of trying to make me look bad or like I want some credit or some other dumb stuff. The shift in tone you see is me talking to a condescending know-it-all who thinks he's better than every one yet proves on a constant basis that his is no better than the turd a dog poops out. Piece out, DF. We're done. Fix it your way, I could care less. I'll fix it correctly.

[mhaeuser]

"This is an insult? I don't see how that's the case...."

You cannot at the same time criticise stealing and call indirectly accusing sb of it "trying to start a talk". I can only repeat myself, if you had serious interest in getting to know whether I "stole your knowledge", you would have PM'd. I'm the topic admin, if I wanted to silence you, I would delete the topic...

 

"You immediately became hostile towards me."

Yes, because I interpreted it as an accusation of stealing, which you even verbalized in later posts.

 

"No, it's targeted to fix all of the issues of dangling pointers left in SMM handlers because RT_Code was moved. It is a broader solution that one specific issue you are saying."

You said you the original RT_code is converted to MMIO and a copy is relocated? When do you copy and do you fix up the PE32 for virtual addresses?

You have totally dropped my point with the global vars... they are part of the RT_code region, which is read-only during XNU runtime. However, AMI RT drivers write to their global variables during runtime. Agreed? Now, that implies that an AMI RT driver cannot work "properly" in the macOS environment without a patch, because either you can execute the RT driver code and it fails to write to its global variables, or you can make it write-enabled (MMIO), but then it will not execute in the first place. If you don't get KPs with your code, I would be interested what is executed and where data is written to. The same goes for current AptioFix.

EDIT: Test results have been interpreted based on a wrong premise.

 

Regarding the rest of the SMM stuff: I guess you know how it works, but that is nowhere near what I or even another person I talked to read from your posts. Whatever you wanted to say, it is not what was received. And yeah, please clearly verbally differ betwen drivers in SMRAM and those that are not.

 

"I didn't say I was working on a fix until much later, you were clearly being a {censored} to me by that point like couldn't possibly comprehend because YOU didn't understand my previous messages."

Yes, I did not understand them. Whether that is me being dumb or you having issues to clearly phrase your thoughts is more than debatable however.

 

"Really because where's the driver, you said it doesn't work? They got to the desktop and wrote NVRAM variables, restarted, and they were still there? Your word is no longer enough proof. Also because you said it doesn't work and removed it....."

Why do you ask if you don't care for the answer? It was removed because of a typo and not working without the rwx kernel patch.

 

"It could have been easy because you could have just starting talking to me about the topic instead of trying to make me look bad"

Again, by no social understanding I can think into "I said this first!" is an invitation to a technical talk. What was received by me (and not only me) was an accusation of theft and that's how it was treated. If you back off your theft accusations and honestly state it was not your intention, I will honestly apologize for how this talk went.

 

"The shift in tone you see is me talking to a condescending know-it-all who thinks he's better than every one yet proves on a constant basis that his is no better than the turd a dog poops out."

Besides that this makes zero sense because I noted your tone calmed down instead of getting worse, I am not somebody who ever left technical discussions shouting others are wrong and confused without actual proofs.

 

"Fix it your way, I could care less. I'll fix it correctly."

The fix is rubbish, this was not a talk about the fix, but about what is causing the problem. That's how it started and that's how I treated it, even though I did notice you were not going that route two posts ago.

[apianti]

This is my last post here. You clearly have a problem with understanding what I say because I said multiple things multiple ways to try to help you understand. How could I accuse you of stealing something I didn't share until later? I think that somehow you took my comment of just being like "I said this like two months ago, and you never responded to me about it. wtf?" as I guess "I said that I had this idea before you, you thief"....? But neither one of us new what each other's method was so why would I think you stole it from me? Or you think that I would think you stole something I didn't know about....?

 

EDIT: I'm using sarcasm too much. Just realized, you are taking some things I say literally but I'm saying them sarcastically.... And that's why I seem like a d i c k...

[mhaeuser]

This is my last post here. You clearly have a problem with understanding what I say because I said multiple things multiple ways to try to help you understand. How could I accuse you of stealing something I didn't share until later? I think that somehow you took my comment of just being like "I said this like two months ago, and you never responded to me about it. wtf?" as I guess "I said that I had this idea before you, you thief"....? But neither one of us new what each other's method was so why would I think you stole it from me? Or you think that I would think you stole something I didn't know about....?

 

EDIT: I'm using sarcasm too much. Just realized, you are taking some things I say literally but I'm saying them sarcastically.... And that's why I seem like a d i c k...

Yes, I took everything literally.

[apianti]

Eh, I think that we both probably escalated this unnecessarily then, lol. Sorry, I am certainly not mad at you, I was making jokes but now that I've thought about it to someone who speaks english as a second language sarcasm usually comes across literally.... I don't think you stole anything from me. Also if I thought you stole it, why would I then outline the method.... But I really do want to talk about fixing it. I'm pretty sure we both understand that the problem is the dangling pointers left in SMM handlers, after relocation of RT_Code areas.

 

EDIT: The question is what is the best and most secure method to protect those code areas while also relocating them?

[mhaeuser]

 

 

Eh, I think that we both probably escalated this unnecessarily then, lol. Sorry, I am certainly not mad at you, I was making jokes but now that I've thought about it to someone who speaks english as a second language sarcasm usually comes across literally.... I don't think you stole anything from me. Also if I thought you stole it, why would I then outline the method.... But I really do want to talk about fixing it. I'm pretty sure we both understand that the problem is the dangling pointers left in SMM handlers, after relocation of RT_Code areas.

 

EDIT: The question is what is the best and most secure method to protect those code areas while also relocating them?

"epic fail" is not a term for this mess... Sorry, let's leave it as "whatever". @_@

A new idea will be tested tomorrow, will share as soon as there are results...

 

Anyway, you said yours fixes stuff. What about the global var (as in "data segment", but afaik a dedicated segment is not mandatory) issue?

EDIT: Test results have been interpreted based on a wrong premise.

[apianti]

"This is an insult? I don't see how that's the case...."

You cannot at the same time criticise stealing and call indirectly accusing sb of it "trying to start a talk". I can only repeat myself, if you had serious interest in getting to know whether I "stole your knowledge", you would have PM'd. I'm the topic admin, if I wanted to silence you, I would delete the topic...

 

Yeah I would have PM'd you which is why I didn't because I didn't think you stole anything. I don't think there was anything for you to know to steal plus nor would I care because I know I could just PM you or talk to you privately in IRC and you would give me credit. I however am not too worried about getting credit. That's like saying I'm the world's largest collector of imaginary four-inch pink horses.

 

"No, it's targeted to fix all of the issues of dangling pointers left in SMM handlers because RT_Code was moved. It is a broader solution that one specific issue you are saying."

You said you the original RT_code is converted to MMIO and a copy is relocated? When do you copy and do you fix up the PE32 for virtual addresses?

You have totally dropped my point with the global vars... they are part of the RT_code region, which is read-only during XNU runtime. However, AMI RT drivers write to their global variables during runtime. Agreed? Now, that implies that an AMI RT driver cannot work "properly" in the macOS environment without a patch, because either you can execute the RT driver code and it fails to write to its global variables, or you can make it write-enabled (MMIO), but then it will not execute in the first place. If you don't get KPs with your code, I would be interested what is executed and where data is written to. The same goes for current AptioFix.

Anyway, you said yours fixes stuff. What about the global var (as in "data segment", but afaik a dedicated segment is not mandatory) issue?

 

Well there's two methods, I think the first one will work but it requires doing much more, the second is a long shot.

 

Method 1.

Make a copy of all the RT_Code images. I think maybe the base address in the load image protocol needs changed but we won't actually rebase the addresses.

Protect the original regions as MMIO.

Override the ConvertPointer (and/or/maybe SetVirtualAddressMap) method to correctly convert pointers in both regions, since only the one will have registered.

The RT_Code copies still have all the MMIO bases, that's cool because once we convert pointers those will be converted to point to the MMIO but the RT_Code will have relocated to the kernel. These should never be touched beyond using the pointers that now point back into the MMIO region. Any physical addresses will be fine but probably irrelevant anyway. There should not be writing to any kernel read/execute only region.

 

EDIT: Forgot a step.

 

Method 2.

Alter the memory map to contain a second copy of all the RT_Code regions but marked MMIO. HAHA. The kernel maps both because it's awesome.

 

Regarding the rest of the SMM stuff: I guess you know how it works, but that is nowhere near what I or even another person I talked to read from your posts. Whatever you wanted to say, it is not what was received. And yeah, please clearly verbally differ betwen drivers in SMRAM and those that are not.

 

Well I was having trouble trying to find a way to describe the two drivers that actually make up the mechanism. I'm still not sure actually. Just DXE driver and SMM driver? Does that make sense to every one what those actually represent? The DXE driver being the runtime component and the SMM driver being the SMM handler?

 

"epic fail" is not a term for this mess... Sorry, let's leave it as "whatever". @_@

Aw, you're good. I think it ended up being productive. We both at least agree that this should be fixable because we both agree what the problem is....

[mhaeuser]

 

 

I know I could just PM you or talk to you privately in IRC and you would give me credit.

Yeah, hence I got pissed @_@

 

Method 1.

Make a copy of all the RT_Code images.

Protect the original regions as MMIO.

The RT_Code copies still have all the MMIO bases, that's cool because once we convert pointers those will be convert to point to the MMIO but the RT_Code will have relocated to the kernel. These should never be touched beyond using the pointers that now point back into the MMIO region. Any physical addresses will be fine but probably irrelevant anyway. There should be not writing to any kernel read/execute only region.

Not only global vars, but also any non-PIC code would point there though... :/

EDIT: Test results have been interpreted based on a wrong premise.

 

Method 2.

Alter the memory map to contain a second copy of all the RT_Code regions but marked MMIO. HAHA. The kernel maps both because it's awesome.

Uhm, second copy?

 

Well I was having trouble trying to find a way to describe the two drivers that actually make up the mechanism. I'm still not sure actually. Just DXE driver and SMM driver? Does that make sense to every one what those actually represent? The DXE driver being the runtime component and the SMM driver being the SMM handler?

The DXE driver exposes SetVariable and is basically a messenger to the SMM driver... Should be clear

[apianti]

Not only global vars, but also any non-PIC code would point there though... :/

 

All EFI code is non-PIC, because PE format is, that's why the need for rebasing loaded images. I don't understand what you mean the only thing that would be pointed to in those regions would be addresses that would be converted to actually point to the MMIO regions, no code should ever execute from the RT_Code region that is relocated. That is merely a way to get all the pointers to convert to the MMIO region and still have RT_Code regions relocated into kernel. Once these pointers are converted to virtual addresses they should be writable because they will point to the MMIO not the restricted RT_Code inside the kernel.

 

Uhm, second copy?

 

Yeah like literally just adding an identical region identifier with a different type. It's a joke.

 

The DXE driver exposes SetVariable and is basically a messenger to the SMM driver... Should be clear

 

Yes, that's clear for NVRAM. If you are using the nomenclature I just said. Otherwise, it probably is.

[mhaeuser]

 

 

All EFI code is non-PIC, because PE format is, that's why the need for rebasing loaded images. I don't understand what you mean the only thing that would be pointed to in those regions would be addresses that would be converted to actually point to the MMIO regions, no code should ever execute from the RT_Code region that is relocated. That is merely a way to get all the pointers to convert to the MMIO region and still have RT_Code regions relocated into kernel. Once these pointers are converted to virtual addresses they should be writable because they will point to the MMIO not the restricted RT_Code inside the kernel.

It will be writable, but not executable. :/ MMIO is +rw -x

From your description, I don't see how having RT_code relocated helps anything. :/

[apianti]

It will be writable, but not executable. :/ MMIO is +rw -x

 

Where did you get that information? Which type would be a good replacement then. What about ACPI_NVS is it read/write/executable? Or is it relocated.

 

EDIT: What about reserved?

 

From your description, I don't see how having RT_code relocated helps anything. :/

 

IDK, maybe not, but at least one needs copied, the system table. Other than that, probably not.

[mhaeuser]

Where did you get that information? Which type would be a good replacement then. What about ACPI_NVS is it read/write/executable? Or is it relocated.

 

 

IDK, maybe not, but at least one needs copied, the system table. Other than that, probably not.

No EFI type is r/w/x, hence the kennel patch I mentioned was needed :/

And yeah, only gST needs to be relocated... Not entirely sure why, probably the pointer in BA is {censored}ed when it isn't

[cecekpawon]

Sorry to interrupt, dont have aptio V either, If kernel patch was needed for this purpose, user need to physically patch the kernel ('on-the-fly' patch will does not work) ?

[joe75]

OMFG!!! I just wasted 20 minutes of my life reading this mess...  

[apianti]

No EFI type is r/w/x, hence the kennel patch I mentioned was needed :/

And yeah, only gST needs to be relocated... Not entirely sure why, probably the pointer in BA is {censored}ed when it isn't

 

Oh I totally misread the XNU code, lol. Not wearing my glasses thought : was a | .... God that is so weird, why are they making those assumptions, you know what would be a better idea than to just patch the kernel to change the type is to patch the call to efi_init(). Then we could just fix all the weird quirks it has, and not relocate anything, correctly assign the correct attributes to the right types of memory. Then we wouldn't even need to do anything else. And that is a simple function that could easily be modified.

 

EDIT: Maybe hibernate_newruntime_map too, but where on earth is that called from. Can't find where it's actually called during resume must be done by boot.efi or something.

EDIT2: Could possibly just patch a call to an override function and a return instruction into those actual functions too if that's more plausible.

 

Sorry to interrupt, dont have aptio V either, If kernel patch was needed for this purpose, user need to physically patch the kernel ('on-the-fly' patch will does not work) ?

 

This will be patched by AptioFix. Which probably/definitely needs a better name....

OMFG!!! I just wasted 20 minutes of my life reading this mess...  

 

You love it.

[THe KiNG]

This is my last post here. ...

+1

 

Eh, I think that we both probably escalated this unnecessarily then...

 

+2

 

Yeah I would have PM'd you which is why I didn't because I didn't think you stole anything. ...

 

+3

All EFI code is non-PIC, because PE format is...

 

+4

Where did you get that information? ...

 

+5

Oh I totally misread the XNU code...

 

That ^^ was the funny part with no comment.

 

Maybe my English is not so good, but I also read it as  "stolen intellectual property", and a normal way to solve it is to talk first, in private, about it.

We saw several times stuff like this on one of the SheHe's sick imaginary alias with a side effect of adding credits for every damn byte patch or even a SMBios dump for a new (i)mac...

Since you made it public IMHO you should just say "I'm sorry" about that, in public, then both of you go back to bench and saving precious time for the actual development.

Yes I know Download-Fritz has a big mouth(should I say fingers?) and sometimes he rush in taking decisions, is what I love and hate about him, but we should accept us as we are otherwise we all left and close the door.

 

P.S. the d i c k is stolen property(usually I am accused for being a..) so stay in line...

[apianti]

Maybe my English is not so good, but I also read it as  "stolen intellectual property", and a normal way to solve it is to talk first, in private, about it.

We saw several times stuff like this on one of the SheHe's sick imaginary alias with a side effect of adding credits for every damn byte patch or even a SMBios dump for a new (i)mac...

Since you made it public IMHO you should just say "I'm sorry" about that, in public, then both of you go back to bench and saving precious time for the actual development.

Yes I know Download-Fritz has a big mouth(should I say fingers?) and sometimes he rush in taking decisions, is what I love and hate about him, but we should accept us as we are otherwise we all left and close the door.

 

P.S. the d i c k is stolen property(usually I am accused for being a..) so stay in line...

 

I'm pretty sure that every one is way overreacting. I said sorry a couple posts back, but I really think it was a misunderstanding more than anything. I was just being extremely sarcastic because I thought he was also being sarcastic.... He was not... Oh well. It's all good.

 

EDIT: To me, I'm most confused because literally there was nothing to steal. What could he possibly have stolen? Something that I have known about for years, that I've also discussed with him many times....? I guess next time I should not make jokes......... But I probably will..... HA

 

EDIT2: You also seemed to get some of my more out there jokes... Which surprises me.... I think you are better at English than you think.

EDIT3: Oh my GOD! You put a crushing joke in there and I didn't even see it until the second edit. SheHe. HAHAHAHA. Another sob story came from there. Also ever see the "resort" it owns? With the stock photos labelled like they are it's family???

[mhaeuser]

EDIT: To me, I'm most confused because literally there was nothing to steal. What could he possibly have stolen? Something that I have known about for years, that I've also discussed with him many times....?

Maybe you now know why I was... mildly unhappy with the comment. v_v

 

Regarding the "global variable problem": It was a conclusion from the test results drawn from false premises... now I'll shut up till there is a working solution.

[bronxteck]

have more respect another one died.... is that number 7 now?.... hmm i wonder if it's copyrighted.