Error message in /var/log/messages after upgrade to R81.20

[Mikael_Trosell]

I upgraded a TE1000X box from R81.10 to R81.20 It seems to work fine except for one problem.

In /var/log/messages there is a large amount of log messages of this type.

Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 19 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5
Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 19 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5
Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 3 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5
Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 3 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5
Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 3 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5
Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 3 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5
Sep 27 14:30:15 2023 FW-TE101 kernel:error: PMC:8778 CPU_ID: 3 arch/x86/kvm/pmc.c, pmc_begin_audit_debug_store - Can't read the guest_ds_area 0x95400300 of cr3 0x1f1e33c0, exception = 5

I had problems with the disk space on /var/ log when the message file was 120 Gbytes...

Has anyone encountered a similar problem? I haven't found anything similar when I searched around

Regards

Mikael Trosell

[Tal_Paz-Fridman]

Hi - have you opened a ticket with TAC? 

I found 2 similar issues and it seems the message are harmless. I suggest opening a ticket so that your case is also investigated. You can point them to this post if needed so that they can refer to the other cases.

[Mikael_Trosell]

Hi,  I'll open a case and see what the result is. I have to increase "log rotation" so that the disk does not get filled in the meantime.

[SuedL_Sec]

Hi Mikael, what was the result of the support case? 

Regards, Viktor

[Mikael_Trosell]

Support wanted more information than I was allowed to send. It works as it should. So I just rotate the syslog file every hour.

[SuedL_Sec]

Hi Mikael, what was the result of the support case?

Regards, Viktor

[Lesley]

Hi Viktor,

This is the related SK article:

https://support.checkpoint.com/results/sk/sk181544

[Thomas_Eichelbu]

Hello, 

yes we have also found this ... 
also i found this SK 181544.

it suggests to "disable the CPU Level Detection"

To disable the high volume of logs in /var/log/messages, disable CPU level detection:
[Expert@FW]# tecli ad at set enable_cpu_level_detection 0

but hey, isnt the CPU Level Detection the reason why customers still use a Sandblast appliance?
what will "tecli ad at set enable_cpu_level_detection 0" do? 
will it disable useful features?

what results did you  get from your TAC cases?

[Mikael_Trosell]

Thanks for the information
The TAC wanted information that I was not allowed to give out.
So I rotated the messages file on an hourly basis.
(and also send the log to a syslog server)

[Thomas_Eichelbu]

Hello, 

we stumbled over it because we analyzed delayed emails ... so i found this messages ... 

i have also opened a TAC case ... 
well i will not accept an answer like this. customers are buying this stuff to secure their environment and have a high degree of  trust in Check Point.
not answering easy questions like this here does nothing to maintain trust! its the opposite.

+ difference between R81.20 and R81.10? why does it pop up in R81.20?
+ what is this message all about?
+ why does CPU Level Detection triggers it?
+ high CPU is triggered, by writting those amount of logs or something else?
+ when i turn CPU Level Detection off, can i still detect malware to the same degree?
+ if the SK says we must turn it off, why is it enbaled in first place?
+ Check Point should update their SK about what is the background here, so that people get informed and so on ...

[Lesley · Accepted solution]

As far as I know if you put this value to zero you will disable CPU level emulation leaving only traditional emulation. 

With CPU level detection you have less of chance that an attacker knows it is operating in a sandbox setup.

So unless in R81.20 something has changed this is no longer relevant I would not disable it. 

[Thomas_Eichelbu]

Hello 

i´v asked our local CP office to double check the statements of TAC.
they say, CPU Level Detection is not that relevant any longer as it was in the past.
CPU Level Detection was/is most beneficial to detect malware with ROP - attacks methods ... 
https://en.wikipedia.org/wiki/Return-oriented_programming

iam asking myself, what is Check Point using in their Cloud to do Threat Emulation? 
do thy use their own Sandblast appliances as well? 
do they run into the same issue as our customer? 
do they turn off CPU Level Detection on their appliance as well?

so iam still not sure what do to.

[PhoneBoy]

It should not impact the security level to disable CPU Level Detection.

[Thomas_Eichelbu]

Today we had a great session with TAC regarding a different thing on a Sandblast appliance ...
During waiting time we always discuss some things and we came to SK  https://support.checkpoint.com/results/sk/sk181544

we checked the state of the CPU level detection, and its turned off!!!

how dare you?

also no more error messages in /var/log/messages.

can it be that CP turned off this feature in one of its HFA`s`?
if yes ... would be nice if it is written somewhere ...

Can somebody from the audience check this as well, we run R81.20 HFA89.
With HFA53 it was still turned on, not its off. Not turned off by us!