Jump to content

Chameleon 2.4svn Official PKG Installer

ErmaC

By ErmaC,
in Chameleon

 Share
4,261 posts in this topic

Recommended Posts

blackosx
blackosx
Posted
Posted

- TEST revision -

 

--> attachicon.gifEnoch_2752_CsrActiveConfig_TEST.zip

 

I add the ability to read a user provided CsrActiveConfig value (Integer) set in the org.chameleon.Boot.plist

Fantastic!. Good job ErmaC. Works here.  :D 

But think using hex notation for the CsrActiveConfig boot option in org.chameleon.Boot.plist rather than an integer would avoid confusion with many noobs.

 

output in bdmesg

[code=auto:0]System Integrity Protection:
- Custom value set by user!
 CsrActiveConfig = 0x67 (01100111)

@Apple. Re ^^ Any chance of adding something similar in your dmesg/asl? ;)

 

Fabio why not add a node in ioreg?

someting like :

"/csr"

         config=01100111

 

...can be usefull :yes:

As long as we have a simple way of reading the current config I'm happy with either method; bootlog as it is, or ioreg node. It would be great if all boot methods had this in their bootlogs or all used the same ioreg node for storing this value.

  • Like 1
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

The SIP setting should not be user readable/changeable (think exploits) and can be checked with help of libsyscall. Just look at the following lines. I'm pretty sure that someone here will get it:

#include 

#include 

#include 


/* Syscall flavors */

#define CSR_OP_CHECK 0

#define CSR_OP_GET_ACTIVE_CONFIG 1

#define CSR_OP_GET_PENDING_CONFIG 2


typedef uint32_t csr_config_t;

typedef uint32_t csr_op_t;


/* Syscalls */

int csr_check(csr_config_t mask);

int csr_get_active_config(csr_config_t *config);

int csr_get_pending_config(csr_config_t *config);


/* Syscall entry point */

int __csrctl(csr_op_t op, void *buffer, size_t size);


int csr_check(csr_config_t mask)

{

	return __csrctl(CSR_OP_CHECK, &mask, sizeof(csr_config_t));

}


int csr_get_active_config(csr_config_t *config)

{

	return __csrctl(CSR_OP_GET_ACTIVE_CONFIG, config, sizeof(csr_config_t));

}


int csr_get_pending_config(csr_config_t *config)

{

	return __csrctl(CSR_OP_GET_PENDING_CONFIG, config, sizeof(csr_config_t));

}

This is for Yosemite, and it may change in El Capitan, but the first two calls will probably stay the same.

  • Like 1
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

The SIP setting should not be user readable/changeable (think exploits)

But on my iMac, RecoveryHD -> Security Configuration tool writes nvram var %g%00%00%00 which ends up in IODeviceTree:/options which shows csr-active-config property. So surely any exploit can either read nvram or check ioreg. No?

Link to comment
Share on other sites
JahStories
JahStories
Posted
Posted

@ErmaC

I've tried this --> zip.gif  Enoch_2752_CsrActiveConfig_TEST.zip   169.63KB   7 downloads

and it correctly sets the csr to 0x03 on boot

 

System Integrity Protection:

- Custom value set by user!
 CsrActiveConfig = 0x03 (00000011)

 

but if i try 

 

<key>CsrActiveConfig</key>

<string>0</string>

 

it loads the default values... 

 

System Integrity Protection:
- Default value
 CsrActiveConfig = 0x01

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

But on my iMac, RecoveryHD -> Security Configuration tool writes nvram var %g%00%00%00 which ends up in IODeviceTree:/options which shows csr-active-config property. So surely any exploit can either read nvram or check ioreg. No?

The problem is that having the NVRAM variable, which isn't there on a Mac (just once after an change) opens a can of worms. And allowing/enabling people to set this in a config file is dead wrong.

 

Note: csrutil status is now what you want ;)

Link to comment
Share on other sites
crazybirdy
crazybirdy
Posted
Posted

Yep use decimal value...

CsrActiveConfig (Hex 0x00) (Binary 00000000) in Decimal is 0

CsrActiveConfig (Hex 0x67) (Binary 01100111) in Decimal is 103

CsrActiveConfig (Hex 0x65) (Binary 01100101) in Decimal is 101

 

ErmaC

 

Test with 2754,

CsrActiveConfig=103 works fine as 0x67,

CsrActiveConfig=0 didn't work as 0x00, but show as 0x01

System Integrity Protection:
    - Default value
      CsrActiveConfig = 0x01

FYI

  • Like 2
Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

The problem is that having the NVRAM variable, which isn't there on a Mac (just once after an change) opens a can of worms.

Hi Pike. Can of worms or not, I can confirm that even with DP7 on my iMac, the csr-active-config nvram var is still present after a reboot. I've just tested by booting in to SnowLeopard, running sudo nvram -c, booting in to DP7 to see csrutil status is enabled without nvram var. Booted in to Recovery HD, disabled SIP with security config app, rebooted in to DP7 and SIP is disabled with nvram var present and IODeviceTree:/options showing csr value. Rebooted DP7 checked again and all values are still there.

 

And allowing/enabling people to set this in a config file is dead wrong.

The only way I can see this being a security problem is maybe an exploit could change the value in a hack's config file and then sit dormant until next boot when it knows it will have permissions to run wild. A possibility I guess.. Maybe Apple could draw the Finder's menu bar in red to visually indicate to the user that the SIP is disabled? Don't know what their UI team would think of that but it would draw attention to it :)

 

Note: csrutil status is now what you want ;)

Yeah. It's now much better.

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

Yeah. Spooky! or maybe it was Pike working secretly for Apple? :P

 

Thing is, since ErmaC added the csr settings to Enoch bootlog I can read SIP settings from that as well as from nvram/ioreg when booted from Oz, Clover or real Mac. So it's no longer a necessity. But still nice to have.

 

EDIT: Pike - That was a joke so don't take it seriously.

  • Like 2
Link to comment
Share on other sites
ErmaC
ErmaC
Posted
  • Author
Posted

@ErmaC

it correctly sets the csr to 0x03 on boot

 

System Integrity Protection:

- Custom value set by user!

 CsrActiveConfig = 0x03 (00000011)

 

but if i try 

 

CsrActiveConfig

0

 

it loads the default values... 

 

System Integrity Protection:

- Default value

 CsrActiveConfig = 0x01

 

 

Test with 2754,

CsrActiveConfig=103 works fine as 0x67,

CsrActiveConfig=0 didn't work as 0x00, but show as 0x01

System Integrity Protection:
    - Default value
      CsrActiveConfig = 0x01

 

 

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

  • Like 5
Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

 

 

 

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..

  • Like 1
Link to comment
Share on other sites
ErmaC
ErmaC
Posted
  • Author
Posted

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

Link to comment
Share on other sites
crazybirdy
crazybirdy
Posted
Posted

 

 

 

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?

  • Like 1
Link to comment
Share on other sites
jsl
jsl
Posted
Posted (edited)

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
Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted (edited)

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
  • Like 2
Link to comment
Share on other sites
meklort
meklort
Posted
Posted

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.

 

  • Like 3
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

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).

  • Like 1
Link to comment
Share on other sites
Micky1979
Micky1979
Posted
Posted

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.

Link to comment
Share on other sites
meklort
meklort
Posted
Posted

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.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...