linux-kernel - Re: [PATCH 1/2] LoongArch: Add pad structure members for explicit alignment

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]

Message-ID: <51051bd7e42378cdf465494389ab76a30ca3acf2.camel@xry111.site>
Date:   Thu, 20 Apr 2023 12:24:55 +0800
From:   Xi Ruoyao <xry111@...111.site>
To:     Qing Zhang <zhangqing@...ngson.cn>,
        WANG Xuerui <kernel@...0n.name>,
        Huacai Chen <chenhuacai@...nel.org>
Cc:     Jiaxun Yang <jiaxun.yang@...goat.com>, loongarch@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] LoongArch: Add pad structure members for explicit
 alignment

On Thu, 2023-04-20 at 10:14 +0800, Qing Zhang wrote:
> > > Ah right. This is UAPI so without *very* concrete and convicing reason 
> > > why the change is not going to impact any potential users, it's gonna 
> > > be a presumed NAK. In other words you must demonstrate (1) why it's 
> > > absolutely necessary to make the change and (2) that it's impossible 
> > > to impact anyone, before any such changes can even be considered.
> > Please ignore all of this. The memory layout is actually the same after 
> > the change due to the padding, I was somehow thinking in big-endian a 
> > few hours ago.

No.  The problem is not related to big endian or little endian. 
Changing the type of this field *can* turn valid user code into
undefined behavior.  `printf(PRIu16 "\n", ptr->dbg_info);` is an
undefined behavior if ptr->dbg_info is a int16_t, because the standard
says so, not because the machine may be big endian.

It is a rare case where the ABI is backward-compatible but the API is
incompatible.

Why not just insert "int16_t pad1[3];" after dbg_info?

> > (The commit message didn't help either, I think both 
> > Ruoyao and me got into the habitual thinking that changes like this are 
> > most likely just churn without real benefits, after *not* seeing the
> > rationale in the commit message which was kinda expected.)
> > > 
> 
> This patch does not change the size of the structure. The structure
> itself is implicitly aligned. We changed it to explicit alignment for
> the convenience of hw_break_get/set (using membuf.left) to calculate the
> offset and prevent breaks. Count overflow.
> 
> With pad explicit alignment, after membuf_write(&to, &info, 
> sizeof(info)); to.left=200-8 bytes,
> Thus,
> membuf_store(&to, addr);
> membuf_store(&to, mask);
> membuf_store(&to, ctrl);
> membuf_zero(&to, sizeof(u32));
> After that, to.left is decremented by 24 bytes each time,
> so the number of breakpoints will not overflow.
> 
> The user support code has not been submitted to the upstream, so
> the current uapi change has no effect.

The problem is once we put a header into the UAPI directory and make a
Linux kernel release, people may start to use it (maybe in a way we
don't expected).

-- 
Xi Ruoyao <xry111@...111.site>
School of Aerospace Science and Technology, Xidian University