Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

joe75
joe75
Posted
Posted 
0x3 enables:
CSR_ALLOW_UNTRUSTED_KEXTS
CSR_ALLOW_UNRESTRICTED_FS

0x67 enables:
CSR_ALLOW_UNTRUSTED_KEXTS 
CSR_ALLOW_UNRESTRICTED_FS
CSR_ALLOW_TASK_FOR_PID
CSR_ALLOW_UNRESTRICTED_DTRACE
CSR_ALLOW_UNRESTRICTED_NVRAM

Does this mean we can't write NVRAM for flag on 0x3?

 

 

Only the csr-config args is restricted, your regular nvram variables are still applied 

Link to comment
Share on other sites
WaldMeister
WaldMeister
Posted
Posted

Only the csr-config args is restricted, your regular nvram variables are still applied 

Adding an example: 

Last login: Fri Aug  7 13:28:18 on console
p70:~ Lex$ nvram -p
efi-boot-device	<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>89405C34-F6F2-4528-B423-78AF12238763</string></dict></dict></dict></array>
fmm-computer-name	P70
security-mode	none
SystemAudioVolumeDB	%ee
backlight-level	%d8%0a
SystemAudioVolume	8
efi-boot-device-data	%02%01%0c%00%d0A%03%0a%00%00%00%00%01%01%06%00%02%1f%03%12%0a%00%04%00%00%00%00%00%04%01*%00%02%00%00%00(@%06%00%00%00%00%00p%f9o%11%00%00%00%004\@%89%f2%f6(E%b4#x%af%12#%87c%02%02%7f%ff%04%00
csr-active-config	%01%00%00%00
p70:~ Lex$ sudo nvram -c
Password:
p70:~ Lex$ nvram -p
efi-boot-device	<array><dict><key>IOMatch</key><dict><key>IOProviderClass</key><string>IOMedia</string><key>IOPropertyMatch</key><dict><key>UUID</key><string>89405C34-F6F2-4528-B423-78AF12238763</string></dict></dict></dict></array>
csr-active-config	%01%00%00%00
p70:~ Lex$

Just noticed, with 0x01 the efi-boot-device will stay also.

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted

Hi,

 

I used the installer for rev 3253 posted here, did not notice untill just now that i have a new dir. Can i remove it? And how did it even get there? 

 

attachicon.gifSchermafbeelding 2015-08-08 om 11.25.28.png

 

I fail to see why you would bother removing for an under 100k of usage on a partition that is never used for anything but booting. That said it appears to be the file system efi driver for 64bit booting you are concerned about. As to getting there I would go with you selecting the option for it in the installer or it being a dependancy of another selection made.

Link to comment
Share on other sites
wegface
wegface
Posted
Posted

I fail to see why you would bother removing for an under 100k of usage on a partition that is never used for anything but booting. That said it appears to be the file system efi driver for 64bit booting you are concerned about. As to getting there I would go with you selecting the option for it in the installer or it being a dependancy of another selection made.

These are not the droids you are looking for.

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

I fail to see why you would bother removing for an under 100k of usage on a partition that is never used for anything but booting. That said it appears to be the file system efi driver for 64bit booting you are concerned about. As to getting there I would go with you selecting the option for it in the installer or it being a dependancy of another selection made.

Mainly because this folder/file is placed outside my EFI partition. It's just a folder with a file in my /Volumes directory. Just wondering how it got there, since it is not because of user interaction. 

Link to comment
Share on other sites
chris1111
chris1111
Posted
Posted

Mainly because this folder/file is placed outside my EFI partition. It's just a folder with a file in my /Volumes directory. Just wondering how it got there, since it is not because of user interaction. 

If you have failure Installer pkg maybe thats happen ?

maybe its a Beta OS X Bug ?

Clover Source Forge Package as never install EFI on  the root

if I am choose UEFI Only .

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

If you have failure Installer pkg maybe thats happen ?

maybe its a Beta OS X Bug ?

Clover Source Forge Package as never install EFI on  the root

if I am choose UEFI Only .

 

Same here. I deleted the folder, will check on the next update if it occurs again. 

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

Same here. I deleted the folder, will check on the next update if it occurs again. 

Did you check if you have no boot file on i386 Folder ?

 

UEFI Only = No boot file 

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Same here. I deleted the folder, will check on the next update if it occurs again. 

I'm not sure that's a bug. I checked my Volumes and, sure enough, no such folder there. :)

 

Also, I found the name (firmwaresyncd aka firmware synced) to be a bit strange. So here's what I found on that. Check it out. I hope it makes things a little bit clearer. :)

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

Running a hack makes everything different. Third party bootloader + unsigned kexts + god knows what else (user specific). You punched a hole in a wall and are trying to patch it back up with tape so it's 'just like new'. That isn't a winning strategy.

 

Truth.  But let's not forget the goals of OSx86 -- When Apple brings out a new feature, we work to get it functioning on non-Apple hardware.  For now, Apple is introducing SIP because it has dumbed-down the OS so much that most Mac users are clueless about security concerns.  We can all pat ourselves on the back for being smarter and more aware than most Mac users but that's not enough as far as I'm concerned.  If Apple is introducing SIP, I'd like to see it work on non-Apple hardware because that's what we do.

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

I thought 0x00 means enable SIP and other security settings?

 

I reinstall to Developer Beta 1,keep 0x67 settings in clover.  Then install all beta updates to beta 6.

 

Now SIP is disabled. 

 

Too much efforts!

Upgrade Clover back.

Set

	<key>RtVariables</key>
	<dict>
		<key>CsrActiveConfig</key>
		<string>0x00</string>
	</dict>
Link to comment
Share on other sites
WaldMeister
WaldMeister
Posted
Posted

I thought 0x00 means enable SIP and other security settings?

 

I reinstall to Developer Beta 1,keep 0x67 settings in clover.  Then install all beta updates to beta 6.

 

Now SIP is disabled. 

After the caches are rebuild, SIP can be enabled again. 

p70:~ Lex$ csrutil status
System Integrity Protection status: enabled.
p70:~ Lex$ nvram -p
....
csr-active-config	%00%00%00%00
p70:~ Lex$
Link to comment
Share on other sites
MTWomg
MTWomg
Posted
Posted

Truth.  But let's not forget the goals of OSx86 -- When Apple brings out a new feature, we work to get it functioning on non-Apple hardware.  For now, Apple is introducing SIP because it has dumbed-down the OS so much that most Mac users are clueless about security concerns.  We can all pat ourselves on the back for being smarter and more aware than most Mac users but that's not enough as far as I'm concerned.  If Apple is introducing SIP, I'd like to see it work on non-Apple hardware because that's what we do.

 

It works just fine. Toss FakeSMC in L/E and ta-da, you can boot. Kext injection does not work anymore though; that needs to get fixed.

Link to comment
Share on other sites
joe75
joe75
Posted
Posted

Adapt and conquer! Take 5 minutes to read about whats going on and learn what needs to be done.. Works just fine.

 

Never mind that we've spent the last 6 years blindly letting our boot managers handle the hacking process of osx86. Most users get lazy as time goes on so this should be a great opportunity to thin the herd and get back to the basics.

  • Like 7
Link to comment
Share on other sites
magnifico
magnifico
Posted
Posted

Adapt and conquer! Take 5 minutes to read about whats going on and learn what needs to be done.. Works just fine.

 

Never mind that we've spent the last 6 years blindly letting our boot managers handle the hacking process of osx86. Most users get lazy as time goes on so this should be a great opportunity to thin the herd and get back to the basics.

Agree. ..agree

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

So, to recap, as of today (August 10th, 2015): can we use CLOVER/kexts/10.11* with CSR set to 0x67 or should we just stop using Clover injection for good (considering SIP is a new feature we want to have natively implemented in non-Apple hardware) and set L/E as our new standard for kexts location and, if so, what CSR flags are we supposed to use?

 

I've been reading and keeping up with stuff and I'm just trying to find the "situation" as of today and as we move forward… :)

 

 

 

* I'm assuming that part of the problem with kexts in the EFI/Clover partition is that it is FAT32, thus not having actual permissions (other than the user that mounts it), which means they can't be owned by `root`, which breaks SIP…?!

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

So, to recap, as of today (August 10th, 2015): can we use CLOVER/kexts/10.11 with CSR set to 0x67 or should we just stop using Clover injection for good (considering SIP is a new feature we want to have natively implemented in non-Apple hardware) and set L/E as our new standard for kexts location and, if so, what CSR flags are we supposed to use?

 

I've been reading and keeping up with stuff and I'm just trying to find the "situation" as of today and as we move forward… :)

As of today, kext injection from EFI is non-functional. I'm sure Slice is working on it.

 

As a workaround, setting SIP to 0x01, 0x03, 0x65, 0x67 and probably other combinations as well (other than 0x00 that is), should give you a bootable and functional system (SIP will be disabled).

 

You don't "need" to add anything, since Clover adds 0x67 by default (hope I'm not wrong about this). So, only if you want to lower the access to let's say 0x01 so that you allow access only to unsigned kexts, will you need to change your RtVariables to reflect this change.

 

As of today, setting the SIP to 0x00 will fully enable it. Which, assuming you got everything booted up and running, should not affect you in any bad way. At least until the next Apple update. When it would be recommended to change your SIP settings to at least 0x01 to allow loading unsigned kexts (especially FakeSMC) from L/E or wherever you might have put them.

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