Re: [PATCH v2 1/2] x86/uaccess: rework user access speculative harden guards

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2024-11-26 10:58, Jan Beulich wrote:
> On 26.11.2024 10:35, Roger Pau Monne wrote:
> > The current guards to select whether user accesses should be 
> > speculative
> > hardened violate Misra rule 20.7, as the UA_KEEP() macro doesn't (and 
> > can't)
> > parenthesize the 'args' argument.
> For my own education: This definitely isn't the only place where we use 
> a
> macro with variable arguments, and where the use of the respective 
> macro
> parameter can't be parenthesized. Given patch 2, why is e.g.
>
> #define emulate_fpu_insn_stub(bytes...)                                 
> \
> do {                                                                    
> \
>     unsigned int nr_ = sizeof((uint8_t[]){ bytes });                    
> \
>     memcpy(get_stub(stub), ((uint8_t[]){ bytes, 0xc3 }), nr_ + 1);      
> \
>     invoke_stub("", "", "=m" (dummy) : "i" (0));                        
> \
>     put_stub(stub);                                                     
> \
> } while (0)
>
> not an issue? The first use of "bytes" is in figure braces, so probably
> fine. Yet the second use is followed by a comma, so unlikely to be 
> okay.
I didn't look at it in detail, but if bytes is expanded inside an 
initialization list, the configuration allows it iirc. I'll need to 
double check, though.
> Somewhat similarly for
>
> #define AMD_OSVW_ERRATUM(osvw_id, ...)  osvw_id, __VA_ARGS__, 0
>
> where we're using the C99 form rather than the GNU extension, and where
> hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
> parenthesizing, when it isn't and can't be.
>
> Isn't it rather the case that variable argument macros need a more 
> general
> deviation, if not an adjustment to the Misra rule? Extending the Cc 
> list
> some ...
> Jan
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)