Jump to content
ErmaC

Chameleon 2.4svn Official PKG Installer

4,336 posts in this topic

Recommended Posts

Advertisement

 

 

 

Thx guys to report this.

I fix it...

I upload the fixed rev soon..

 

But one question... is pure COSMETICS.. what about the output?

Something like that in bdmesg? (I wrote it by hand not a real bdmesg output)

 

System Integrity Protection status: enabled (Custom Configuration).

CsrActiveConfig: 0xff (11111111)
    Apple Internal: disabled
    Kext Signing: disabled
    Filesystem Protections: disabled
    Debugging Restrictions: disabled
    DTrace Restrictions: disabled
    NVRAM Protections: disabled

I'm tempt to say... this is an unsupported configuration, but I'm running on an Hackintosh and this is a TEST.
:P

 

ErmaC

 

Fabio for me is ok, but you can make the csr config a variable in the header (boot.h)? I Think i can recuperate it in FileNVRAM to be published under /option ....just to try when I have time..

Share this post


Link to post
Share on other sites

Fabio for me is ok, but you can make the csr config a variable in the header (boot.h)? I Think i can recuperate it in FileNVRAM to be published under /option ....just to try when I have time..

 

You mean the key in the org.chameleon.Boot.plist?

... you can read it... is already defined in boot.h

#define KCsrActiveConfig        "CsrActiveConfig"
yep you have to compile the edited FileNVRAM to read it...

but the value is not stored anywhere... you have to re-read it

if ( getIntForKey(KCsrActiveConfig, &crsValue, &bootInfo->chameleonConfig) && (crsValue >= 0 && crsValue <= 255) )...
do the job
..else...
(default config)
 

ErmaC

Share this post


Link to post
Share on other sites

yep is more easy to have "crsValue" as macro otherwise I need to scan all partitions... actual limitation... (weeh! as appear to me  ^_^ )

Share this post


Link to post
Share on other sites

 

 

 

Thx guys to report this.

I fix it...

I upload the fixed rev soon..

 

But one question... is pure COSMETICS.. what about the output?

Something like that in bdmesg? (I wrote it by hand not a real bdmesg output)

 

System Integrity Protection status: enabled (Custom Configuration).

CsrActiveConfig: 0xff (11111111)
    Apple Internal: disabled
    Kext Signing: disabled
    Filesystem Protections: disabled
    Debugging Restrictions: disabled
    DTrace Restrictions: disabled
    NVRAM Protections: disabled

I'm tempt to say... this is an unsupported configuration, but I'm running on an Hackintosh and this is a TEST.
:P

 

ErmaC

 

2754_v2 works fine here too. :yes:

Test with CsrActiveConfig=0,101,103 as pics.

You see, /S/L/E/VoodooHDA.kext didn't work with CsrActiveConfig=0.

post-61100-0-76204400-1440120549_thumb.gif

post-61100-0-84943700-1440120555_thumb.gif

post-61100-0-84054200-1440120562_thumb.gif

But I still have question, Do we need BooterConfig=0x28 as Clover?

Share this post


Link to post
Share on other sites

I upload a new revision 2754_v2

http://www.insanelymac.com/forum/files/download/71-enoch/

 

ErmaC

Thanks for this new version which works for me in DP7.

But its booting screen seems abnormal in Intel HD 4600 or AMD 6870 display:

1. GUI=Yes was disabled (no difference from GUI=No)

2. GUI=No  only the first booting device was visible. The others need downward arrow to make it visible and enter for select.

I think it's pure cosmetic not related to its main functions.

 

[solved]

This bug occurs only for some display cards only such as AMD 6870 or Intel HD 4600.

I found if it's installed in Nvidia 780 or AMD 5770 there is no such an error or bug.

Edited by jsl

Share this post


Link to post
Share on other sites

Pike, great!

btw why not make this kext compatiblle for all bootloaders? 

 

#define FILE_NVRAM_PATH "/Extra/NVRAM/nvram.plist"

 

to

 

#define FILE_NVRAM_PATH "/nvram.kext.plist" or "/usr/standalone/nvram.plist" (writable path)

Edited by Micky1979

Share this post


Link to post
Share on other sites

For those of you playing along at home, I'm going to do a slight information dump about FileVNRAM:

 

FileNVRAM was developed in conjunction with the same chameleon module. Yes, you *can* use it without bootloader support, however, if you do so there is a race condition that occurs. This can result in early program / kernel code using un-set or incorrect nvram variables. Once the boot completes, the variables will be updated in the kext, however, at this point the incorrect variables may have been read out already.

 

So... the kext itself (as-is) can be used with any bootloader (I often use it on my mac), however, there are cases where things can break with it if the bootloader also doesn't support it.

 

The kext itself doesn't need any modifications to be supported by Clover, you just need to pass in the proper information in the device tree. Once that's done, the initial nvram values will be populated, in addition to the path to store the nvram file.

 

Finally, please note that if you do *not* have bootloader support, the OS will take longer to startup. There are a couple of kexts that block the boot process by waiting for the NVRAM kext to register with the PlatformExpert. If bootloader support is not available, FileNVRAM will wait to register until after vfs / root have finished mounting. This means that the blocking kexts are now waiting longer (usually FileNVRAM on chameleon finishes initializing well before root is mounted) and as a result, the boot process will take longer.

 

Pike:

I noticed you changed the file io read/write functions. Yes, it's good to verify that the ctx is non-null (which should be added in my repo), however, you've modified the routines to now be FileNVRAM specific, they were originally designed to be fairly generic and not specific to the kext.

Additionally, I've noticed that you changed the target from 10.4 to 10.11. The original kext was setup so that it works on any x86 and x86_64 os that apple has released. This was done by design.

Other than that... it's kinda hard to see if you changed anything else in the diff (well, except replacing all spaces with tabs)

 

 

For anyone wanting to do development with FileNVRAM:

As for any extensions to FileNVRAM (such as in relation to CSR): Please note that the FileNVRAM module provides a public API for chameleon that allows it to set, delete and modify nvram variables. These should be used if you want to change the behavior, instead of modifying the module directly. If you have a diff that you would like me to add to the official repo, you can do so using the following link: https://public.xzenue.com/differential/diff/create/Once you do so, I'll add any comments about things that I'd like changed before merging it in.

Related to the CSR, FileNVRAM (the root context) needs to be able to write to a file on disk, as such, there really isn't a good way to properly secure this kext on 10.11 to block root / normal users from writing to this file, while still allowing FileNVRAM access. I haven't tried 10.11 yes, so there might be a way to grant special privileges to the kext itself, but again, I haven't looked into it.

 

Share this post


Link to post
Share on other sites

Hi meklort, FileNVRAM.kext compiled targeting old OSes was not working.Not tested Pike's fork yet using original deployment target, but I will, reporting back soon.

Share this post


Link to post
Share on other sites

Pike, great!

btw why not make this kext compatiblle for all bootloaders?

I used /Extra/NVRAM since that to me is the most logical place to have files.

 

@meklort,

 

With boot loader support you mean the injection of properties by the boot loader. Correct? I hope that chosen/nvram is deleted afterwards.

 

I did not change a lot. The noted mCtx checks, regular file checks, and I didn't liked the fact that calls to read_buffer() and write_buffer() could potentially be misused.

 

I have since changed the deployment target to 10.7. This was the lowest possible one that allowed me to compile the kext.

 

p.s. I did not test the kext to verify it (I no longer have a hack).

Share this post


Link to post
Share on other sites

The FileNVRAM module (.dilyb) only work here if I delete the interal kernelpatcher functions, then also a little modification to the function that scan bios for the uuid. I'm not at home, later I'll provide more about..

With module nvram.plist place, takes more sense, I was meant for booloader support.

Share this post


Link to post
Share on other sites

With boot loader support you mean the injection of properties by the boot loader. Correct? I hope that chosen/nvram is deleted afterwards.

 

I did not change a lot. The noted mCtx checks, regular file checks, and I didn't liked the fact that calls to read_buffer() and write_buffer() could potentially be misused.

 

Correct, I do mean injecting the properties via the bootloader.

 

As for deleting the properties after use, see below:

    if (bootnvram)

    {

        copyEntryProperties(NULL, bootnvram);

        bootnvram->detachFromParent(root, gIODTPlane);

    }

 
Please note that this deletes /choosen/nvram, but causes /options/nvram to be populated, just like the standard Apple NVRAM kext. Again, I haven't looked at the 10.11 kext, but this behaves the same way as prior OS releases.
 

 

Ya, the ctx check is definitely good.

As for the mCtx usage inside of it, my way and your way can both be misused.

In the previous case, the root ctx was not used by default, and a kext had to provide the ctx on it's own. Granted, you could just grab the cached value from the kext...

With your changes, another kext simply has to call the function and they'll automatically get the root context.

 

Perhaps a safer option would be to make the symbol private /  force inline of the function so that it can't be called by anyone else. (easily). Then again, the source is available, and it uses public APIs form Apple, so it's not like someone couldn't just re-use the code.

 

 

Anyway, you're correct, you cannot target 10.4 with the latest xcode. I have a separate build machine specifically setup with Xcode 3.6 for building FileNVRAM for release.

Share this post


Link to post
Share on other sites

Hi meklort,

 

As you said, I've noticed importants slowdowns while using your kext without the module on Enoch during boot time, something like 8 seconds without it and 20 seconds with it.

I've even tried using it with the module but it makes the system crash on boot, exactly, stuck on a black screen at login and eventually with the spinning "beach ball"...

 

Btw, it seems that having nvram.kext correctly working could be a backdoor to fool the CSR status and do other stuff, am I right?

 

Not everyone here is a coder, sometimes an easier explanation could be a wiser decision. IMHO

 

:)

Share this post


Link to post
Share on other sites

 

Pike the kext can't be loaded running kextxache:

kxld[com.xZenue.kext.FileNVRAM]: The following symbols are unresolved for this kext:
kxld[com.xZenue.kext.FileNVRAM]:  AppleNVRAM::setPath(OSString*)
kxld[com.xZenue.kext.FileNVRAM]:  _mCtx
Link failed (error code 5).
and also running kextutil:
sudo kextutil /System/Library/Extensions/FileNVRAM.kext 
/System/Library/Extensions/FileNVRAM.kext is invalid; can't resolve dependencies.
/System/Library/Extensions/FileNVRAM.kext is invalid; can't resolve dependencies.
/System/Library/Extensions/FileNVRAM.kext is invalid; can't resolve dependencies.
Diagnostics for /System/Library/Extensions/FileNVRAM.kext:
Validation Failures: 
    Info dictionary missing required property/value: 
        CFBundleIdentifier


Warnings: 
    Personality has no CFBundleIdentifier; the kext's identifier will be inserted when sending to the IOCatalogue: 
        FileNVRAM
the second issue because "com.xZenue.kext.FileNVRAM" is not set as bundle identifier in Info.plist, but I have trouble to fix _mCtx issue in write/read_buffer function (no longer exist). Any advice?

Share this post


Link to post
Share on other sites

 

 

 

Well, instead of including kext as mkext (kernelpatcher hang?), just leave separate files.

Pike, attached FileNVRAM.dylib module that match your FileNVRAM.kext fork(nvram.plist path), however see my last post.

 

Source included with compiler errors fixed.  Can be compiled at same time along with Chameleon/Enoch, just put into /i368/modules and replace the already compiled version.

FileNVRAM source+precompiled module.zip

Edited by Micky1979

Share this post


Link to post
Share on other sites

 

kxld[com.xZenue.kext.FileNVRAM]: The following symbols are unresolved for this kext:
kxld[com.xZenue.kext.FileNVRAM]:  AppleNVRAM::setPath(OSString*)
kxld[com.xZenue.kext.FileNVRAM]:  _mCtx
Link failed (error code 5).
 

 

mCtx is referenced by FileIO.c

 

This is compiled as a C file and cannot access C++ names without having them managed first.

Additionally, mCtx is a member variable of the FileNVRAM class. You cannot access it without the class pointer.

 

If read/write_buffer needs to access it, these functions need to instead be moved into the class as member functions so that they can access the variable.

 

So... the short answer is... revert the changes to that file, and it'll work. Alternatively, move the functions into FileNVRAM.cpp (and set the names properly, and declare them properly in FileNVRAM.h)

 

Hi meklort,

 

As you said, I've noticed important slowdowns while using your kext without the module on Enoch during boot time, something like 8 seconds without it and 20 seconds with it.

I've even tried using it with the module but it makes the system crash on boot, exactly, stuck on a black screen at login and eventually with the spinning "beach ball"...

 

Btw, it seems that having nvram.kext correctly working could be a backdoor to fool the CSR status and do other stuff, am I right?

 

Not everyone here is a coder, sometimes an easier explanation could be a wiser decision. IMHO

 

:)

 

The simple explanations is... OS X blocks until NVRAM is available. The module makes it happen early for FileNVRAM. If you don't use the kext, apple's default one takes over and lets the boot happen quickly.

The other explanations were more for people with a programming background.

 

Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly.

 

As mentioned before... I've never tried the kext or module with 10.11 (or 10.10), so I didn't know there was a problem. Additionally... I received a grand total of 0 bug reports. I also don't think anyone has sent me an email or a pm about it either. If nobody tells me there's an issue, I'll assume there isn't one. 

 

So... please file bug reports if you find them.

Share this post


Link to post
Share on other sites

 

Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly.

 

Thanks for additional explanation. You think I can do something like:

 

if(is_module_loaded("FileNVRAM.dylib", 0)){

    AddNvramVariable(.....);

}

else {

    // use o.c.B.p or default value

}

 

to add what we need?

 

good night to all :)

Share this post


Link to post
Share on other sites

@Meklort

 

Yes, FileNVRAM could be use to assist the CSR changes for 10.11, but there are security implications that have to be taken into account properly.

Can you be more precise?

 

Thanks

Share this post


Link to post
Share on other sites

Pike the kext can't be loaded running kextxache...

Sorry. I was in a hurry and did run kextutil to verify it. I did commit some (untested) changes. I have no idea why Xcode 7 (Beta) changed the CFBundleIndentifier, because it sure wasn't me. Anyway. It compiled and the error is gone.

 

Edit: Confirmed working (thanks Bry)!

 

@meklort,

 

Yes. It is better to move read_buffer() and write_buffer() to FileNVRAM.cpp as that takes care of the security issues. Now you can only overwrite /Extra/NVRAM/nvram.plist but so can any other process.

Share this post


Link to post
Share on other sites

Yes. It is better to move read_buffer() and write_buffer() to FileNVRAM.cpp as that takes care of the security issues. Now you can only overwrite /Extra/NVRAM/nvram.plist but so can any other process.

 

Please explain this security issue to me.

 

You've hard coded the kext to now use /Extra/NVRAM/nvram.plist.

If someone previously wanted to modify a file, they could do so as root. Sure, they could tell FileNVRAM to point to a different file path, but they'd have to be root to do so (only root can write nvram variables).

 

So... you're previous options were... be root... or be root. How is that any different from the new option of.... be root?

My understanding is that root is now locked out from modifying certain system files, and so would this kext as it uses the root context.

 

 

Perhaps a *good* fix would be something like the following:

(1) Does the file pointed to exists?

(2) If File does not exists, continue, file path is OK

(3) If file does exist, verify that it's contents are an XML dictionary in the FileNVRMA format.

(4) If contents OK, file path is ok

(5) If contents are bad, yell at the user and don't use the path.

 

 

 

Thanks for additional explanation. You think I can do something like:

 

if(is_module_loaded("FileNVRAM.dylib", 0)){

    AddNvramVariable(.....);

}

else {

    // use o.c.B.p or default value

}

 

to add what we need?

 

good night to all :)

Something like that yes, although I don't remember the proper usage of is_module_loaded (it might just be "FileNVRAM").

 

Also, if you are calling nay symbols in FileNVRAM directly, you must either

(1) Be running as a module

or

(2) Look up the symbols at runtime using the module system apis. 

 

 

@Meklort

Can you be more precise?

 

Thanks

FileNVRAM is not a signed kext. So, to load it, you have to disable the CSR, or bypass it somehow. Additionally, the nvram file the FileNVRAM uses should use the additional security enhancements that Apple's added to lock out even root from touching it (and still have some way to touch it by itself).

Share this post


Link to post
Share on other sites

Please explain this security issue to me.

 

You've hard coded the kext to now use /Extra/NVRAM/nvram.plist.

If someone previously wanted to modify a file, they could do so as root. Sure, they could tell FileNVRAM to point to a different file path, but they'd have to be root to do so (only root can write nvram variables).

 

So... you're previous options were... be root... or be root. How is that any different from the new option of.... be root?

My understanding is that root is now locked out from modifying certain system files, and so would this kext as it uses the root context.

 

Perhaps a *good* fix would be something like the following:

(1) Does the file pointed to exists?

(2) If File does not exists, continue, file path is OK

(3) If file does exist, verify that it's contents are an XML dictionary in the FileNVRMA format.

(4) If contents OK, file path is ok

(5) If contents are bad, yell at the user and don't use the path.

Yes. I indeed hardcoded the path. And for good reason. Apps can call functions in kexts without being root. Just look at the Intel Power Gadget. Then look at what kexts Apple blocked, being low level kext because they won't allow everything. I did ask of writing to disk, from a kext, is a good idea and they said nope. Don't do it. Move code to a sandboxed app and let the app handle the writes to disk.

 

I already check the file type (regular file required) and my local tree already checks for a proper XML dictionary.

Share this post


Link to post
Share on other sites

Yes. I indeed hardcoded the path. And for good reason. Apps can call functions in kexts without being root. Just look at the Intel Power Gadget. Then look at what kexts Apple blocked, being low level kext because they won't allow everything. I did ask of writing to disk, from a kext, is a good idea and they said nope. Don't do it. Move code to a sandboxed app and let the app handle the writes to disk.

 

I already check the file type (regular file required) and my local tree already checks for a proper XML dictionary.

Pike,

 

Apps *cannot* call arbitrary functions in a kext. There are a specific subset of functions that they can call. FileNVRAM validate that the user is root before allowing the write to continue. Read the code, this is *already* taken into account.

 

Yes, It's well know that File IO is strongly discouraged. It's easy to mess up.

Share this post


Link to post
Share on other sites

Pike,

 

Apps *cannot* call arbitrary functions in a kext. There are a specific subset of functions that they can call. FileNVRAM validate that the user is root before allowing the write to continue. Read the code, this is *already* taken into account.

 

Yes, It's well know that File IO is strongly discouraged. It's easy to mess up.

I wouldn't say otherwise. I wrote the app and BOOM. Nothing is stopping me.

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By dgsga
      Can I propose a new subforum be created for the new OpenCorePkg OpenCore front end being created by vit9696 and others, it is a fantastic piece of work:
      https://github.com/acidanthera/OpenCorePkg
      Even at version 0.1 it runs my Mojave 10.14.4 setup very nearly flawlessly. It consists of a 10KB bootstrap BootX64.efi and a 200KB OpenCore.efi OS loader. All configuration is done using a very well documented config.plist 
       
       
    • By kylon
      Cloud Clover Editor is an open source application that allows you to manage the configuration of various Hackintosh Bootloaders.

      Open Cloud Clover Editor
       
      Cloud Clover Editor Wiki
      Cloud Clover Editor Sources
       
       
      Features
      Supports Clover EFI, Ozmosis, Chameleon, OpenCore GUI and Text Editor Mode CCE Bank Mobile friendly and more...  
      Officially supported browsers
      Chrome 42+ Microsoft Edge 14+ Firefox 39+ Safari 10+ Opera 29+ Opera Mobile 12+ Chrome for Android 75+ Firefox for Android 67+  
       
      Credits
      mackie100 - took some ideas from his app Clover EFI dev team Eric Slivka - new serial number Virtual1 - new serial number cecekpawon - PHP 5.3.3 patch, , help with the ACPI Loader Mode flag and more Micky1979 - Clover flying editor  (Discontinued) crusher. - Help with the ACPI Loader Mode flag Download-Fritz - Help with the ACPI Loader Mode flag Pavo - Ozmosis fields and values stehor - Ozmosis fields and values Sherlocks - General help and support gujiangjiang - General help and support  
      Please let me know if i forgot you!
    • By cvad
      View File Bootdisk Utility
      Make bootable USB Flash Disk for MAC OS X with Latest Clover bootloader revision fast and easy by one click! under OS Windows.
      Special utility from cvad & russian MAC community for new hackintosh users.
       
      Enjoy...
       
      For more information and complete instructions please see this topic.
       
       
       
       
      Feel free to "Rate File"
      Submitter cvad Submitted 04/28/2013 Category Bootloaders  
    • By ErmaC
      Slice is glad to present a new EFI bootloader.

      CLOVER
      Now version 2 rEFIt based.


      It is open source based on different projects: Chameleon, rEFIt, XNU, VirtualBox. The main is EDK2 latest revision.
      I also want to thank all who help Slice with the development. Credits and copyrights remain in the sources.
      https://sourceforge.net/projects/cloverefiboot/?source=directory
      There is a WIKI 
      http://clover-wiki.zetam.org/
      Main features:


      If you have a question please provide outputs from DarwinDumper (formed from Trauma tool). Thanks Trauma!
      Continued by blackosx and STLVNUB.
      Post#2 CloverGrower - create Clover by yourself Post#3 Downloads Post#4 Installation of the bootloader Post#5 How to do UEFI boot Post#6 How to use - common words Post#7 Calculator for Automatic DSDT fix Post#8 Instructions for GraphicsInjector Post#9 ATIConnector patching Post#10 Any kexts patching with some Samples Post#11 CustomEDID Post#12 Hiding unnecessary menu entries Post#13 Instruction for DSDT corrections to do DeviceInjection works Post#14 Development Post#15 Themes Post#16 About kexts injection Post#17 Instructions for P- and C-states generator Post#18 Patching DSDT to get Sleep working Post#19 CPU settings and geekbench Post#20 ACPI tables loading Post#21 DSDTmini Post#22 Custom SMBios Post#23 F.A.Q. Post#24 iCloudFix Post#25 Using mouse. Post#26 How to make orange icons to be metallic Post#27 How to make software RAID (by Magnifico) Post#28 How to modify InstallESD.dmg (by shiecldk) Post#29 Config.plist settings Post#30 Using extra kexts and skipping kernelcache Post#31 Choosing EFI drivers Post#32 Configuration files Post#33 Automatic config.plist creating Post#34 Custom DSDT patches Post#35 How to do sleep/wake working with UEFI BOOT Post#36 DeviceID substitution (FakeID) Post#37 Using Custom OS Icons Post#38 Hibernation Post#39 Floating regions Post#41 Property List Editor Post#42 Blocking Bad Kext Post#43 AAPL,slot-name Post#44 FakeCPUID for unsupported CPU Post#45 Multiple Boot Options - to write into UEFI BIOS boot menu Post#46 How to install Windows UEFI Post#47 How to speedup Clover boot Post#48 Info.plist patching Post#49 Arbitrary device injection Post#50 Non-Standard Legacy Boot Files Post#51 Reboot to Windows UEFI from Mac OSX Post#52 Deprecated Features Post#53 Using UDK2018 Post#54 Device Properties Post#55 Scalable themes Post#56 How to search Clover mistakes (bisection) -----------------
       
      Slice:
      I edited all posts in the thread to correspond to actual Clover revision.
      Please install Clover at least 2652 and use new instructions.
×