Jump to content

Clover Problems and Solutions

ErmaC

By ErmaC,
in Clover Development

 Share
3,206 posts in this topic

Recommended Posts

cecekpawon
cecekpawon
Posted
Posted

Hello Slice, has been long time since my last contribute. I would like to propose ascii table header fixes discovered by @theracermaster, with ACPI -> DSDT -> Fixes -> FixHeader_0003 = TRUE. It will replace char (< 0x20) / (> 0x7E) with 0x3F ('?') on table header to avoid panics without dropping the whole table.

 

** Cannot compile & test this patches for you, but working well with my forked, hope you enjoy.

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

Hello Slice, has been long time since my last contribute. I would like to propose ascii table header fixes discovered by @theracermaster, with ACPI -> DSDT -> Fixes -> FixHeader_0003 = TRUE. It will replace char ( 0x7E) with 0x3F ('?') on table header to avoid panics without dropping the whole table.

 

** Cannot compile & test this patches for you, but working well with my forked, hope you enjoy.

OK, I will implement this. With some precautions  B)

If DropSSDT then your patch will not work although it is invented for MATS table first of all.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Dell Laptops do not have MATS. failpoint is BGRT table if you care to also include

Sure, all tables will be included. 

 

@cecekpawon

FixAsciiTableHeader() is not possible in place because initially ACPI tables located in ROM. ReadOnlyMemory.

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted

Hi. I noticed some changes about SIP under High Sierra. Here are the patches, thanks to https://www.idelta.info/archives/secure-kernel-extension-loading-in-macos-high-sierra/  :)

files.zip

 

There're also pre-compiled binaries if someone wants:

new.zip

 

Some tips:

- To disable SIP since 10.13 DP3/PB2 entirely, you need to set CsrActiveConfig = 0x3FF

- The name of the new flag is still unknown, but it doesn't really matter, we may change the name after releasing new XNU

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

If DropSSDT then your patch will not work although it is invented for MATS table first of all.

 

You are right, no patch with DropOEM.

 

FixAsciiTableHeader() is not possible in place because initially ACPI tables located in ROM. ReadOnlyMemory.

 

Sorry, I dont have 10.13 to test, and my tables doesnt have such problems.

Im also not sure about ROM, but in fact, all (except user loaded table) get applied if I force to replace all char with "X".

Please ignore if you think this still not possible yo Slice :)

post-1101532-0-47473100-1500343646_thumb.jpg

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

Hi. I noticed some changes about SIP under High Sierra. Here are the patches, thanks to https://www.idelta.info/archives/secure-kernel-extension-loading-in-macos-high-sierra/  :)

attachicon.giffiles.zip

 

There're also pre-compiled binaries if someone wants:

attachicon.gifnew.zip

 

Some tips:

- To disable SIP since 10.13 DP3/PB2 entirely, you need to set CsrActiveConfig = 0x3FF

- The name of the new flag is still unknown, but it doesn't really matter, we may change the name after releasing new XNU

 

 

I try CsrActiveConfig = 0x3FF in my config.plist under High Sierra. Is normal csrutil status as the old CsrActiveConfig (image below)? I don't know. Can you tell me.

 

Sorry for my english

post-1110743-0-13191900-1500383018_thumb.png

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted

I try CsrActiveConfig = 0x3FF in my config.plist under High Sierra. Is normal csrutil status as the old CsrActiveConfig (image below)? I don't know. Can you tell me.

 

Sorry for my english

Yes. As far as I know the output of csrutil doesn't change.

You could try

nvram -p | grep csr
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted

 

Yes. As far as I know the output of csrutil doesn't change.

You could try

nvram -p | grep csr

 

On Sierra, csrutil status just show "System Integrity Protection status: disabled."

 

 

Under High Sierra (left image) and under Sierra (right image), with nvram -p  | grep csr  command:

post-1110743-0-26681700-1500388577.png

post-1110743-0-96545300-1500389098_thumb.png

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

That should be fine.

Sorry

 

I don't understand: on Sierra, i use 0x67 = SIP Disabled completely

 

Under High Sierra, I use CsrActiveConfig = 0x3FF. Status = SIP enabled but with custom configuration disabled. The two output seems to be different with nvram -p

Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted

Sorry

 

I don't understand: on Sierra, i use 0x67 = SIP Disabled completely[/size]

 

Under High Sierra, I use [/size]CsrActiveConfig = 0x3FF. Status = SIP enabled but with custom configuration disabled. The two output seems to be different with nvram -p

Did u disable SIP on Sierra via RecoveryHD with "csrutil disable" using Terminal..?

If so, just use same method for High Sierra and check again for it's status. Both outputs are same then?

Link to comment
Share on other sites
PMheart
PMheart
Posted
Posted

Sorry

 

I don't understand: on Sierra, i use 0x67 = SIP Disabled completely

 

Under High Sierra, I use CsrActiveConfig = 0x3FF. Status = SIP enabled but with custom configuration disabled. The two output seems to be different with nvram -p

Actually no. Under Sierra you need 0x1FF to disable completely rather than 0x67.

Don't really trust what you've seen from `csrutil status`.

The “csrutil” tool set config bit 0, 1, 2, 4, 5 and 6 (0x77), which will turn off almost the entire rootless/SIP except the kernel debugger. If we only need to turn off kext signing check, 0x1 could be set instead of 0x67. The “rootless=0” put into boot-args should never be used because it would turn off ALL these protection and it will also be deprecated in the public release of 10.11.

From: https://www.idelta.info/archives/sip-rootless-internal-in-el-capitan/

So 0x77 doesn't fully disable SIP, at least, CSR_ALLOW_KERNEL_DEBUGGER is still enabled. Please take a glance on Clover GUI -> Options -> System Parameters -> System Integrity Protection (You may need the Clover binaries I provided here I guess), then check everything there, back to the last menu, you'll see CsrActiveConfig = 0x3FF.

Did u disable SIP on Sierra via RecoveryHD with "csrutil disable" using Terminal..?

If so, just use same method for High Sierra and check again for it's status. Both outputs are same then?

Yes. But you see 0x67 not because you've run `csrutil disable` but Clover injects this by default. Thus note that any operation with `csrutil` to set SIP status will make no sense unless you set CsrActiveConfig = 0xFFFF in config.plist, otherwise Clover will still set something anyway. (i.e. If CsrActiveConfig doesn't exist then Clover will set it to 0x67 by default as I said, else Clover shall gather it from user's config.plist)

And also. Like I said here, `csrutil disable` doesn't mean fully disabling SIP.

  • Like 3
Link to comment
Share on other sites
Badruzeus
Badruzeus
Posted
Posted

Yes. But you see 0x67 not because you've run `csrutil disable` but Clover injects this by default. Thus note that any operation with `csrutil` to set SIP status will make no sense unless you set CsrActiveConfig = 0xFFFF in config.plist, otherwise Clover will still set something anyway. (i.e. If CsrActiveConfig doesn't exist then Clover will set it to 0x67 by default as I said, else Clover shall gather it from user's config.plist)

And also. Like I said here, `csrutil disable` doesn't mean fully disabling SIP.

Great explanation; thanks again  :)

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

Hi. I noticed some changes about SIP under High Sierra. Here are the patches, thanks to https://www.idelta.info/archives/secure-kernel-extension-loading-in-macos-high-sierra/  :)

attachicon.giffiles.zip

 

There're also pre-compiled binaries if someone wants:

attachicon.gifnew.zip

 

Some tips:

- To disable SIP since 10.13 DP3/PB2 entirely, you need to set CsrActiveConfig = 0x3FF

- The name of the new flag is still unknown, but it doesn't really matter, we may change the name after releasing new XNU

Accepted.

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

You are right, no patch with DropOEM.

 

 

Sorry, I dont have 10.13 to test, and my tables doesnt have such problems.

Im also not sure about ROM, but in fact, all (except user loaded table) get applied if I force to replace all char with "X".

Please ignore if you think this still not possible yo Slice :)

 

It may be that your firmware remapped the tables into regular memory and marked it appropriately as ACPI(_NVS) but there are many firmwares that map the ROM directly to memory and you should not modify this.

Link to comment
Share on other sites
cecekpawon
cecekpawon
Posted
Posted

and you should not modify this.

 

I hope (gSettings.FixDsdt & FIX_HEADERS) could be useful not just for this purpose in the futures. Maybe Clover need to do filtering by user given table Signature/TableId like drop table to be more safety?

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

Seriously?

 

Regrettably, yes. There are even firmwares that directly expose the ROM, effectively as NVRAM. You can determine this by SPD information, in this case the ROM is actually reported back as memory device. It's pretty amazing, right???

I hope (gSettings.FixDsdt & FIX_HEADERS) could be useful not just for this purpose in the futures. Maybe Clover need to do filtering by user given table Signature/TableId like drop table to be more safety?

 

Really you shouldn't modify any ACPI memory at all because you can't know whether you are actually modifying the ROM or not, you can brick firmwares.

 

EDIT: I would imagine that most EFI firmwares are not going to have an issue with this though, as the interface to modify the tables is standardized.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

The FD should be mapped read-only, shouldn't it? At least on AMI fw, writes are done via a protocol that uses device commands...

 

Yeah, I would hope. That's why I edited and added the part about most EFI firmwares probably being fine.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

it kp's too early to get a log. thats what made finding the acpi table issue so tricky in the first place.

debug.log anyway will be created before the KP.

 

I probably see why BGRT panics. cecekpawon proposition is not enough.

Test 4122

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