linux-kernel - Re: [PATCH v6 0/2] x86/resctrl: Track llc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 8 Apr 2024 15:44:00 +0800
From: Haifeng Xu <haifeng.xu@...pee.com>
To: Reinette Chatre <reinette.chatre@...el.com>, james.morse@....com
Cc: fenghua.yu@...el.com, babu.moger@....com, bp@...en8.de,
 tglx@...utronix.de, mingo@...hat.com, dave.hansen@...ux.intel.com,
 hpa@...or.com, peternewman@...gle.com, x86@...nel.org,
 linux-kernel@...r.kernel.org, corbet@....net, linux-doc@...r.kernel.org
Subject: Re: [PATCH v6 0/2] x86/resctrl: Track llc_occupancy of RMIDs in limbo
 list



On 2024/3/30 07:06, Reinette Chatre wrote:
> Hi Haifeng,
> 
> On 3/19/2024 1:30 AM, Haifeng Xu wrote:
>> After removing a monitor group, its RMID may not be freed immediately
>> unless its llc_occupancy is less than the re-allocation threshold. If
>> turning up the threshold, the RMID can be reused. In order to know how
>> much the threshold should be, it's necessary to acquire the llc_occupancy.
>>
>> The patch series provides a new tracepoint to track the llc_occupancy.
> 
> There seems to be a problem with the DKIM attestation. Here is what I see
> when I download this series:
> 
>     $ b4 am -Q 20240319083039.223088-1-haifeng.xu@...pee.com
>     Grabbing thread from lore.kernel.org/all/20240319083039.223088-1-haifeng.xu@...pee.com/t.mbox.gz
>     Analyzing 3 messages in the thread
>     Looking for additional code-review trailers on lore.kernel.org
>     Checking attestation on all messages, may take a moment...
>     ---
>       ✗ [PATCH v6 1/2] x86/resctrl: Rename pseudo_lock_event.h to trace.h
>       ✗ [PATCH v6 2/2] x86/resctrl: Add tracepoint for llc_occupancy tracking
>     ---
>       ✗ BADSIG: DKIM/shopee.com
>     ---
>     Total patches: 2
>     ---
> 

Hi, Reinette,

I can also reproduced it. After digging into it, I found that our DKIM signature header
has 't' and 'x' flags. They are recommended as a means to help identify spam.

t= is the DKIM signature timestamp.
x= is the DKIM signature expiration time.

The source code of DKIM Validation can be seen in dkim/__init__.py(line 351), I paste it
here.

 343     if b'x' in sig:
 344         if re.match(br"\d+$", sig[b'x']) is None:
 345             raise ValidationError(
 346               "x= value is not a decimal integer (%s)" % sig[b'x'])
 347         x_sign = int(sig[b'x'])
 348         now = int(time.time())
 349         slop = 36000 # 10H leeway for mailers with inaccurate clocks
 350         if x_sign < now - slop:
 351             raise ValidationError(
 352                 "x= value is past (%s)" % sig[b'x'])
 353             if x_sign < t_sign:
 354                 raise ValidationError(
 355                     "x= value is less than t= value (x=%s t=%s)" %
 356                     (sig[b'x'], sig[b't']))

The expiry time is less than the time point you download the patch, so the validation
fails. If I comment out these lines, this series can be successfully downloaded.

The signature is only valid for a week. So if you use b4 to download the patch series,
It's best to do it in a week after the patch is sent.

Thanks.


> The patches look good to me. Thank you very much for adding this.
> Please resubmit with the DKIM attestation fixed and then you can add:
> 
> | Reviewed-by: Reinette Chatre <reinette.chatre@...el.com>
> 
> Reinette

Thanks for your review.