All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/17] Enable strict compile-time memcpy() fortify checks
@ 2021-12-13 22:33 Kees Cook
  2021-12-13 22:33 ` [PATCH 01/17] KVM: x86: Replace memset() "optimization" with normal per-field writes Kees Cook
                   ` (18 more replies)
  0 siblings, 19 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, linux-kernel

Hi,

This is "phase 2" (of several phases) to hardening the kernel against
memcpy-based buffer overflows. With nearly all compile-time fixes
landed, the next step is to turn on the warning globally to keep future
compile-time issues from happening, and let us take the step towards
run-time checking (and towards a new API for flexible array structures).

This series is based on latest linux-next, and several patches here
have already been taken by subsystem maintainers but haven't appeared
in linux-next yet, and are noted below.

-Kees

refactoring patches expected to be going via subsystem trees:
    sata_fsl: Use struct_group() for memcpy() region
	https://lore.kernel.org/lkml/23527f89-d098-ab6b-f3c9-a8a395e32df5@opensource.wdc.com/
    ath11k: Use memset_startat() for clearing queue descriptors
	https://lore.kernel.org/lkml/163777372886.11557.5551795598856429949.kvalo@codeaurora.org/

refactoring patches going via my topic tree due to having no current response:
    net/mlx5e: Use struct_group() for memcpy() region
	https://lore.kernel.org/lkml/20211118183748.1283069-1-keescook@chromium.org/
    net/mlx5e: Avoid field-overflowing memcpy()
	https://lore.kernel.org/lkml/20211209053402.2202206-1-keescook@chromium.org/
    media: omap3isp: Use struct_group() for memcpy() region
	https://lore.kernel.org/lkml/20211118184352.1284792-1-keescook@chromium.org/
    drbd: Use struct_group() to zero algs
	https://lore.kernel.org/lkml/20211118203712.1288866-1-keescook@chromium.org/
    dm integrity: Use struct_group() to zero struct journal_sector
	https://lore.kernel.org/lkml/20211118203640.1288585-1-keescook@chromium.org/
    iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl
	https://lore.kernel.org/lkml/20211118202335.1285836-1-keescook@chromium.org/

refactoring patches going via my topic tree due to Acks:
    KVM: x86: Replace memset() "optimization" with normal per-field writes
	https://lore.kernel.org/lkml/202108181605.44C504C@keescook/
    RDMA/mlx5: Use memset_after() to zero struct mlx5_ib_mr
	https://lore.kernel.org/lkml/YbByJSkBgLRp5S8V@unreal/
    intel_th: msu: Use memset_startat() for clearing hw header
	https://lore.kernel.org/lkml/87sfyzi97l.fsf@ashishki-desk.ger.corp.intel.com/
    IB/mthca: Use memset_startat() for clearing mpt_entry
	https://lore.kernel.org/lkml/20211118202126.1285376-1-keescook@chromium.org/
    scsi: lpfc: Use struct_group() to initialize struct lpfc_cgn_info
	https://lore.kernel.org/lkml/1164349c-93a5-ebb8-94aa-dbe03957c40f@gmail.com/

fortify changes going via my topic tree:
    fortify: Detect struct member overflows in memcpy() at compile-time
    fortify: Detect struct member overflows in memmove() at compile-time
    fortify: Detect struct member overflows in memset() at compile-time
    fortify: Work around Clang inlining bugs


 arch/x86/boot/compressed/misc.c               |   3 +-
 arch/x86/kvm/emulate.c                        |   9 +-
 arch/x86/kvm/kvm_emulate.h                    |   6 +-
 arch/x86/lib/memcpy_32.c                      |   1 +
 drivers/ata/sata_fsl.c                        |  10 +-
 drivers/block/drbd/drbd_main.c                |   3 +-
 drivers/block/drbd/drbd_protocol.h            |   6 +-
 drivers/block/drbd/drbd_receiver.c            |   3 +-
 drivers/hwtracing/intel_th/msu.c              |   4 +-
 drivers/infiniband/hw/cxgb4/cm.c              |   5 +-
 drivers/infiniband/hw/mlx5/mlx5_ib.h          |   4 +-
 drivers/infiniband/hw/mthca/mthca_mr.c        |   3 +-
 drivers/md/dm-integrity.c                     |   9 +-
 drivers/media/platform/omap3isp/ispstat.c     |   5 +-
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h   |   2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en.h  |   6 +-
 .../net/ethernet/mellanox/mlx5/core/en/xdp.c  |   4 +-
 .../net/ethernet/mellanox/mlx5/core/en_tx.c   |   2 +-
 drivers/net/wireless/ath/ath11k/hal_rx.c      |  13 +-
 drivers/scsi/lpfc/lpfc.h                      |  90 ++++---
 drivers/scsi/lpfc/lpfc_init.c                 |   4 +-
 include/linux/fortify-string.h                | 245 +++++++++++++-----
 include/linux/if_vlan.h                       |   6 +-
 include/uapi/linux/omap3isp.h                 |  21 +-
 lib/Makefile                                  |   3 +-
 lib/string_helpers.c                          |   6 +
 .../read_overflow2_field-memcpy.c             |   5 +
 .../read_overflow2_field-memmove.c            |   5 +
 .../write_overflow_field-memcpy.c             |   5 +
 .../write_overflow_field-memmove.c            |   5 +
 .../write_overflow_field-memset.c             |   5 +
 scripts/test_fortify.sh                       |   8 +-
 security/Kconfig                              |   2 +-
 33 files changed, 344 insertions(+), 164 deletions(-)
 create mode 100644 lib/test_fortify/read_overflow2_field-memcpy.c
 create mode 100644 lib/test_fortify/read_overflow2_field-memmove.c
 create mode 100644 lib/test_fortify/write_overflow_field-memcpy.c
 create mode 100644 lib/test_fortify/write_overflow_field-memmove.c
 create mode 100644 lib/test_fortify/write_overflow_field-memset.c

-- 
2.30.2


^ permalink raw reply	[flat|nested] 43+ messages in thread
* [PATCH 01/17] KVM: x86: Replace memset() "optimization" with normal per-field writes
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 02/17] net/mlx5e: Avoid field-overflowing memcpy() Kees Cook
                   ` (17 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, Sean Christopherson, linux-kernel

From: Sean Christopherson <seanjc@google.com>

Explicitly zero select fields in the emulator's decode cache instead of
zeroing the fields via a gross memset() that spans six fields. gcc and
clang are both clever enough to batch the first five fields into a single
quadword MOV, i.e. memset() and individually zeroing generate identical
code.

Removing the wart also prepares KVM for FORTIFY_SOURCE performing
compile-time and run-time field bounds checking for memset().

No functional change intended.

Reported-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Link: https://lore.kernel.org/lkml/YR0jIEzEcUom/7rd@google.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/kvm/emulate.c     | 9 +++++++--
 arch/x86/kvm/kvm_emulate.h | 6 +-----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 28b1a4e57827..7401a3133e17 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -5381,8 +5381,13 @@ static int fastop(struct x86_emulate_ctxt *ctxt, fastop_t fop)
 
 void init_decode_cache(struct x86_emulate_ctxt *ctxt)
 {
-	memset(&ctxt->rip_relative, 0,
-	       (void *)&ctxt->modrm - (void *)&ctxt->rip_relative);
+	/* Clear fields that are set conditionally but read without a guard. */
+	ctxt->rip_relative = false;
+	ctxt->rex_prefix = 0;
+	ctxt->lock_prefix = 0;
+	ctxt->rep_prefix = 0;
+	ctxt->regs_valid = 0;
+	ctxt->regs_dirty = 0;
 
 	ctxt->io_read.pos = 0;
 	ctxt->io_read.end = 0;
diff --git a/arch/x86/kvm/kvm_emulate.h b/arch/x86/kvm/kvm_emulate.h
index 68b420289d7e..bc1fecacccd4 100644
--- a/arch/x86/kvm/kvm_emulate.h
+++ b/arch/x86/kvm/kvm_emulate.h
@@ -336,11 +336,7 @@ struct x86_emulate_ctxt {
 		fastop_t fop;
 	};
 	int (*check_perm)(struct x86_emulate_ctxt *ctxt);
-	/*
-	 * The following six fields are cleared together,
-	 * the rest are initialized unconditionally in x86_decode_insn
-	 * or elsewhere
-	 */
+
 	bool rip_relative;
 	u8 rex_prefix;
 	u8 lock_prefix;
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 02/17] net/mlx5e: Avoid field-overflowing memcpy()
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
  2021-12-13 22:33 ` [PATCH 01/17] KVM: x86: Replace memset() "optimization" with normal per-field writes Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 03/17] net/mlx5e: Use struct_group() for memcpy() region Kees Cook
                   ` (16 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Saeed Mahameed, Leon Romanovsky, David S. Miller,
	Jakub Kicinski, Alexei Starovoitov, Daniel Borkmann,
	Jesper Dangaard Brouer, John Fastabend, netdev, linux-rdma, bpf,
	linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.

Use flexible arrays instead of zero-element arrays (which look like they
are always overflowing) and split the cross-field memcpy() into two halves
that can be appropriately bounds-checked by the compiler.

We were doing:

	#define ETH_HLEN  14
	#define VLAN_HLEN  4
	...
	#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
	...
        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
	...
        struct mlx5_wqe_eth_seg  *eseg = &wqe->eth;
        struct mlx5_wqe_data_seg *dseg = wqe->data;
	...
	memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);

target is wqe->eth.inline_hdr.start (which the compiler sees as being
2 bytes in size), but copying 18, intending to write across start
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
(8 bytes).

struct mlx5e_tx_wqe {
        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */
        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */
        struct mlx5_wqe_data_seg   data[];               /*    32     0 */

        /* size: 32, cachelines: 1, members: 3 */
        /* last cacheline: 32 bytes */
};

struct mlx5_wqe_eth_seg {
        u8                         swp_outer_l4_offset;  /*     0     1 */
        u8                         swp_outer_l3_offset;  /*     1     1 */
        u8                         swp_inner_l4_offset;  /*     2     1 */
        u8                         swp_inner_l3_offset;  /*     3     1 */
        u8                         cs_flags;             /*     4     1 */
        u8                         swp_flags;            /*     5     1 */
        __be16                     mss;                  /*     6     2 */
        __be32                     flow_table_metadata;  /*     8     4 */
        union {
                struct {
                        __be16     sz;                   /*    12     2 */
                        u8         start[2];             /*    14     2 */
                } inline_hdr;                            /*    12     4 */
                struct {
                        __be16     type;                 /*    12     2 */
                        __be16     vlan_tci;             /*    14     2 */
                } insert;                                /*    12     4 */
                __be32             trailer;              /*    12     4 */
        };                                               /*    12     4 */

        /* size: 16, cachelines: 1, members: 9 */
        /* last cacheline: 16 bytes */
};

struct mlx5_wqe_data_seg {
        __be32                     byte_count;           /*     0     4 */
        __be32                     lkey;                 /*     4     4 */
        __be64                     addr;                 /*     8     8 */

        /* size: 16, cachelines: 1, members: 3 */
        /* last cacheline: 16 bytes */
};

So, split the memcpy() so the compiler can reason about the buffer
sizes.

"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe
nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object
code changes (i.e. only source line number induced differences and
optimizations).

Cc: Saeed Mahameed <saeedm@nvidia.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: bpf@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h     | 6 +++---
 drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index e77c4159713f..5d8e0a712313 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -225,7 +225,7 @@ static inline int mlx5e_get_max_num_channels(struct mlx5_core_dev *mdev)
 struct mlx5e_tx_wqe {
 	struct mlx5_wqe_ctrl_seg ctrl;
 	struct mlx5_wqe_eth_seg  eth;
-	struct mlx5_wqe_data_seg data[0];
+	struct mlx5_wqe_data_seg data[];
 };
 
 struct mlx5e_rx_wqe_ll {
@@ -242,8 +242,8 @@ struct mlx5e_umr_wqe {
 	struct mlx5_wqe_umr_ctrl_seg   uctrl;
 	struct mlx5_mkey_seg           mkc;
 	union {
-		struct mlx5_mtt inline_mtts[0];
-		struct mlx5_klm inline_klms[0];
+		DECLARE_FLEX_ARRAY(struct mlx5_mtt, inline_mtts);
+		DECLARE_FLEX_ARRAY(struct mlx5_klm, inline_klms);
 	};
 };
 
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
index 2f0df5cc1a2d..efae2444c26f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
@@ -341,8 +341,10 @@ mlx5e_xmit_xdp_frame(struct mlx5e_xdpsq *sq, struct mlx5e_xmit_data *xdptxd,
 
 	/* copy the inline part if required */
 	if (sq->min_inline_mode != MLX5_INLINE_MODE_NONE) {
-		memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
+		memcpy(eseg->inline_hdr.start, xdptxd->data, sizeof(eseg->inline_hdr.start));
 		eseg->inline_hdr.sz = cpu_to_be16(MLX5E_XDP_MIN_INLINE);
+		memcpy(dseg, xdptxd->data + sizeof(eseg->inline_hdr.start),
+		       MLX5E_XDP_MIN_INLINE - sizeof(eseg->inline_hdr.start));
 		dma_len  -= MLX5E_XDP_MIN_INLINE;
 		dma_addr += MLX5E_XDP_MIN_INLINE;
 		dseg++;
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 03/17] net/mlx5e: Use struct_group() for memcpy() region
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
  2021-12-13 22:33 ` [PATCH 01/17] KVM: x86: Replace memset() "optimization" with normal per-field writes Kees Cook
  2021-12-13 22:33 ` [PATCH 02/17] net/mlx5e: Avoid field-overflowing memcpy() Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 04/17] media: omap3isp: " Kees Cook
                   ` (15 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Saeed Mahameed, Leon Romanovsky, David S. Miller,
	Jakub Kicinski, netdev, linux-rdma, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.

Use struct_group() in struct vlan_ethhdr around members h_dest and
h_source, so they can be referenced together. This will allow memcpy()
and sizeof() to more easily reason about sizes, improve readability,
and avoid future warnings about writing beyond the end of h_dest.

"pahole" shows no size nor member offset changes to struct vlan_ethhdr.
"objdump -d" shows no object code changes.

Cc: Saeed Mahameed <saeedm@nvidia.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +-
 include/linux/if_vlan.h                         | 6 ++++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
index 7fd33b356cc8..ee7ecb88adc1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
@@ -208,7 +208,7 @@ static inline void mlx5e_insert_vlan(void *start, struct sk_buff *skb, u16 ihs)
 	int cpy1_sz = 2 * ETH_ALEN;
 	int cpy2_sz = ihs - cpy1_sz;
 
-	memcpy(vhdr, skb->data, cpy1_sz);
+	memcpy(&vhdr->addrs, skb->data, cpy1_sz);
 	vhdr->h_vlan_proto = skb->vlan_proto;
 	vhdr->h_vlan_TCI = cpu_to_be16(skb_vlan_tag_get(skb));
 	memcpy(&vhdr->h_vlan_encapsulated_proto, skb->data + cpy1_sz, cpy2_sz);
diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 8420fe504927..2be4dd7e90a9 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -46,8 +46,10 @@ struct vlan_hdr {
  *	@h_vlan_encapsulated_proto: packet type ID or len
  */
 struct vlan_ethhdr {
-	unsigned char	h_dest[ETH_ALEN];
-	unsigned char	h_source[ETH_ALEN];
+	struct_group(addrs,
+		unsigned char	h_dest[ETH_ALEN];
+		unsigned char	h_source[ETH_ALEN];
+	);
 	__be16		h_vlan_proto;
 	__be16		h_vlan_TCI;
 	__be16		h_vlan_encapsulated_proto;
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 04/17] media: omap3isp: Use struct_group() for memcpy() region
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (2 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 03/17] net/mlx5e: Use struct_group() for memcpy() region Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 05/17] sata_fsl: " Kees Cook
                   ` (14 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields. Wrap the target region
in struct_group(). This additionally fixes a theoretical misalignment
of the copy (since the size of "buf" changes between 64-bit and 32-bit,
but this is likely never built for 64-bit).

FWIW, I think this code is totally broken on 64-bit (which appears to
not be a "real" build configuration): it would either always fail (with
an uninitialized data->buf_size) or would cause corruption in userspace
due to the copy_to_user() in the call path against an uninitialized
data->buf value:

omap3isp_stat_request_statistics_time32(...)
    struct omap3isp_stat_data data64;
    ...
    omap3isp_stat_request_statistics(stat, &data64);

int omap3isp_stat_request_statistics(struct ispstat *stat,
                                     struct omap3isp_stat_data *data)
    ...
    buf = isp_stat_buf_get(stat, data);

static struct ispstat_buffer *isp_stat_buf_get(struct ispstat *stat,
                                               struct omap3isp_stat_data *data)
...
    if (buf->buf_size > data->buf_size) {
            ...
            return ERR_PTR(-EINVAL);
    }
    ...
    rval = copy_to_user(data->buf,
                        buf->virt_addr,
                        buf->buf_size);

Regardless, additionally initialize data64 to be zero-filled to avoid
undefined behavior.

Fixes: 378e3f81cb56 ("media: omap3isp: support 64-bit version of omap3isp_stat_data")
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/media/platform/omap3isp/ispstat.c |  5 +++--
 include/uapi/linux/omap3isp.h             | 21 +++++++++++++--------
 2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispstat.c b/drivers/media/platform/omap3isp/ispstat.c
index 5b9b57f4d9bf..68cf68dbcace 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -512,7 +512,7 @@ int omap3isp_stat_request_statistics(struct ispstat *stat,
 int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
 					struct omap3isp_stat_data_time32 *data)
 {
-	struct omap3isp_stat_data data64;
+	struct omap3isp_stat_data data64 = { };
 	int ret;
 
 	ret = omap3isp_stat_request_statistics(stat, &data64);
@@ -521,7 +521,8 @@ int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
 
 	data->ts.tv_sec = data64.ts.tv_sec;
 	data->ts.tv_usec = data64.ts.tv_usec;
-	memcpy(&data->buf, &data64.buf, sizeof(*data) - sizeof(data->ts));
+	data->buf = (uintptr_t)data64.buf;
+	memcpy(&data->frame, &data64.frame, sizeof(data->frame));
 
 	return 0;
 }
diff --git a/include/uapi/linux/omap3isp.h b/include/uapi/linux/omap3isp.h
index 87b55755f4ff..d9db7ad43890 100644
--- a/include/uapi/linux/omap3isp.h
+++ b/include/uapi/linux/omap3isp.h
@@ -162,6 +162,7 @@ struct omap3isp_h3a_aewb_config {
  * struct omap3isp_stat_data - Statistic data sent to or received from user
  * @ts: Timestamp of returned framestats.
  * @buf: Pointer to pass to user.
+ * @buf_size: Size of buffer.
  * @frame_number: Frame number of requested stats.
  * @cur_frame: Current frame number being processed.
  * @config_counter: Number of the configuration associated with the data.
@@ -176,10 +177,12 @@ struct omap3isp_stat_data {
 	struct timeval ts;
 #endif
 	void __user *buf;
-	__u32 buf_size;
-	__u16 frame_number;
-	__u16 cur_frame;
-	__u16 config_counter;
+	__struct_group(/* no tag */, frame, /* no attrs */,
+		__u32 buf_size;
+		__u16 frame_number;
+		__u16 cur_frame;
+		__u16 config_counter;
+	);
 };
 
 #ifdef __KERNEL__
@@ -189,10 +192,12 @@ struct omap3isp_stat_data_time32 {
 		__s32	tv_usec;
 	} ts;
 	__u32 buf;
-	__u32 buf_size;
-	__u16 frame_number;
-	__u16 cur_frame;
-	__u16 config_counter;
+	__struct_group(/* no tag */, frame, /* no attrs */,
+		__u32 buf_size;
+		__u16 frame_number;
+		__u16 cur_frame;
+		__u16 config_counter;
+	);
 };
 #endif
 
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 05/17] sata_fsl: Use struct_group() for memcpy() region
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (3 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 04/17] media: omap3isp: " Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
                   ` (13 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, Jens Axboe, linux-ide, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.

Use struct_group() in struct command_desc around members acmd and fill,
so they can be referenced together. This will allow memset(), memcpy(),
and sizeof() to more easily reason about sizes, improve readability,
and avoid future warnings about writing beyond the end of acmd:

In function 'fortify_memset_chk',
    inlined from 'sata_fsl_qc_prep' at drivers/ata/sata_fsl.c:534:3:
./include/linux/fortify-string.h:199:4: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
  199 |    __write_overflow_field();
      |    ^~~~~~~~~~~~~~~~~~~~~~~~

Cc: Jens Axboe <axboe@kernel.dk>
Cc: linux-ide@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/ata/sata_fsl.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index 3b31a4f596d8..c5a2c1e9ed6b 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -246,8 +246,10 @@ enum {
 struct command_desc {
 	u8 cfis[8 * 4];
 	u8 sfis[8 * 4];
-	u8 acmd[4 * 4];
-	u8 fill[4 * 4];
+	struct_group(cdb,
+		u8 acmd[4 * 4];
+		u8 fill[4 * 4];
+	);
 	u32 prdt[SATA_FSL_MAX_PRD_DIRECT * 4];
 	u32 prdt_indirect[(SATA_FSL_MAX_PRD - SATA_FSL_MAX_PRD_DIRECT) * 4];
 };
@@ -531,8 +533,8 @@ static enum ata_completion_errors sata_fsl_qc_prep(struct ata_queued_cmd *qc)
 	/* setup "ACMD - atapi command" in cmd. desc. if this is ATAPI cmd */
 	if (ata_is_atapi(qc->tf.protocol)) {
 		desc_info |= ATAPI_CMD;
-		memset((void *)&cd->acmd, 0, 32);
-		memcpy((void *)&cd->acmd, qc->cdb, qc->dev->cdb_len);
+		memset(&cd->cdb, 0, sizeof(cd->cdb));
+		memcpy(&cd->cdb, qc->cdb, qc->dev->cdb_len);
 	}
 
 	if (qc->flags & ATA_QCFLAG_DMAMAP)
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (4 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 05/17] sata_fsl: " Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-14  3:56   ` kernel test robot
                     ` (6 more replies)
  2021-12-13 22:33 ` [PATCH 07/17] fortify: Detect struct member overflows in memmove() " Kees Cook
                   ` (12 subsequent siblings)
  18 siblings, 7 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, linux-kernel

memcpy() is dead; long live memcpy()

tl;dr: In order to eliminate a large class of common buffer overflow
flaws that continue to persist in the kernel, have memcpy() (under
CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct
member when they have a known size. This would have caught all of the
memcpy()-related buffer write overflow flaws identified in at least the
last three years.

Background and analysis:

While stack-based buffer overflow flaws are largely mitigated by stack
canaries (and similar) features, heap-based buffer overflow flaws continue
to regularly appear in the kernel. Many classes of heap buffer overflows
are mitigated by FORTIFY_SOURCE when using the strcpy() family of
functions, but a significant number remain exposed through the memcpy()
family of functions.

At its core, FORTIFY_SOURCE uses the compiler's __builtin_object_size()
internal[0] to determine the available size at a target address based on
the compile-time known structure layout details. It operates in two
modes: outer bounds (0) and inner bounds (1). In mode 0, the size of the
enclosing structure is used. In mode 1, the size of the specific field
is used. For example:

	struct object {
		u16 scalar1;	/* 2 bytes */
		char array[6];	/* 6 bytes */
		u64 scalar2;	/* 8 bytes */
		u32 scalar3;	/* 4 bytes */
		u32 scalar4;	/* 4 bytes */
	} instance;

__builtin_object_size(instance.array, 0) == 22, since the remaining size
of the enclosing structure starting from "array" is 22 bytes (6 + 8 +
4 + 4).

__builtin_object_size(instance.array, 1) == 6, since the remaining size
of the specific field "array" is 6 bytes.

The initial implementation of FORTIFY_SOURCE used mode 0 because there
were many cases of both strcpy() and memcpy() functions being used to
write (or read) across multiple fields in a structure. For example,
it would catch this, which is writing 2 bytes beyond the end of
"instance":

	memcpy(&instance.array, data, 24);

While this didn't protect against overwriting adjacent fields in a given
structure, it would at least stop overflows from reaching beyond the
end of the structure into neighboring memory, and provided a meaningful
mitigation of a subset of buffer overflow flaws. However, many desirable
targets remain within the enclosing structure (for example function
pointers).

As it happened, there were very few cases of strcpy() family functions
intentionally writing beyond the end of a string buffer. Once all known
cases were removed from the kernel, the strcpy() family was tightened[1]
to use mode 1, providing greater mitigation coverage.

What remains is switching memcpy() to mode 1 as well, but making the
switch is much more difficult because of how frustrating it can be to
find existing "normal" uses of memcpy() that expect to write (or read)
across multiple fields. The root cause of the problem is that the C
language lacks a common pattern to indicate the intent of an author's
use of memcpy(), and is further complicated by the available compile-time
and run-time mitigation behaviors.

The FORTIFY_SOURCE mitigation comes in two halves: the compile-time half,
when both the buffer size _and_ the length of the copy is known, and the
run-time half, when only the buffer size is known. If neither size is
known, there is no bounds checking possible. At compile-time when the
compiler sees that a length will always exceed a known buffer size,
a warning can be deterministically emitted. For the run-time half,
the length is tested against the known size of the buffer, and the
overflowing operation is detected. (The performance overhead for these
tests is virtually zero.)

It is relatively easy to find compile-time false-positives since a warning
is always generated. Fixing the false positives, however, can be very
time-consuming as there are hundreds of instances. While it's possible
some over-read conditions could lead to kernel memory exposures, the bulk
of the risk comes from the run-time flaws where the length of a write
may end up being attacker-controlled and lead to an overflow.

Many of the compile-time false-positives take a form similar to this:

	memcpy(&instance.scalar2, data, sizeof(instance.scalar2) +
					sizeof(instance.scalar3));

and the run-time ones are similar, but lack a constant expression for the
size of the copy:

	memcpy(instance.array, data, length);

The former is meant to cover multiple fields (though its style has been
frowned upon more recently), but has been technically legal. Both lack
any expressivity in the C language about the author's _intent_ in a way
that a compiler can check when the length isn't known at compile time.
A comment doesn't work well because what's needed is something a compiler
can directly reason about. Is a given memcpy() call expected to overflow
into neighbors? Is it not? By using the new struct_group() macro, this
intent can be much more easily encoded.

It is not as easy to find the run-time false-positives since the code path
to exercise a seemingly out-of-bounds condition that is actually expected
may not be trivially reachable. Tightening the restrictions to block an
operation for a false positive will either potentially create a greater
flaw (if a copy is truncated by the mitigation), or destabilize the kernel
(e.g. with a BUG()), making things completely useless for the end user.

As a result, tightening the memcpy() restriction (when there is a
reasonable level of uncertainty of the number of false positives), needs
to first WARN() with no truncation. (Though any sufficiently paranoid
end-user can always opt to set the panic_on_warn=1 sysctl.) Once enough
development time has passed, the mitigation can be further intensified.

Given the potential frustrations of weeding out all the false positives
when tightening the run-time checks, it is reasonable to wonder if these
changes would actually add meaningful protection. Looking at just the
last three years, there are 23 identified flaws with a CVE that mention
"buffer overflow", and 11 are memcpy()-related buffer overflows.

(For the remaining 12: 7 are array index overflows that would be
mitigated by systems built with CONFIG_UBSAN_BOUNDS=y: CVE-2019-0145,
CVE-2019-14835, CVE-2019-14896, CVE-2019-14897, CVE-2019-14901,
CVE-2019-17666, CVE-2021-28952. 2 are miscalculated allocation
sizes which could be mitigated with memory tagging: CVE-2019-16746,
CVE-2019-2181. 1 is an iovec buffer bug maybe mitigated by memory tagging:
CVE-2020-10742. 1 is a type confusion bug mitigated by stack canaries:
CVE-2020-10942. 1 is a string handling logic bug with no mitigation I'm
aware of: CVE-2021-28972.)

At my last count on an x86_64 allmodconfig build, there are 25,018 calls
to memcpy(). With callers instrumented to report all places where the
buffer size is known but the length remains unknown (i.e. a run-time
bounds check is added), we can count how many new run-time bounds checks
are added when the destination and source arguments of memcpy() are
changed to use "mode 1" bounds checking: 1540. In addition, there were
146 new compile-time warnings to evaluate and fix.

With this it's also possible to compare the places where the known 11
memcpy() flaw overflows happened against the resulting list of potential
new bounds checks, as a measure of potential efficacy of the tightened
mitigation. Much to my surprise, horror, and delight, all 11 flaws would
have been detected by the newly added run-time bounds checks, making this
a distinctly clear mitigation improvement: 100% coverage for memcpy()
flaws, with a possible 2 orders of magnitude gain in coverage over
existing but undiscovered run-time dynamic length flaws, against only 6%
of all callers maybe gaining a false positive run-time check, with fewer
than 150 new compile-time instances needing evaluation.

Specifically these would have been mitigated:
CVE-2020-24490 https://git.kernel.org/linus/a2ec905d1e160a33b2e210e45ad30445ef26ce0e
CVE-2020-12654 https://git.kernel.org/linus/3a9b153c5591548612c3955c9600a98150c81875
CVE-2020-12653 https://git.kernel.org/linus/b70261a288ea4d2f4ac7cd04be08a9f0f2de4f4d
CVE-2019-14895 https://git.kernel.org/linus/3d94a4a8373bf5f45cf5f939e88b8354dbf2311b
CVE-2019-14816 https://git.kernel.org/linus/7caac62ed598a196d6ddf8d9c121e12e082cac3a
CVE-2019-14815 https://git.kernel.org/linus/7caac62ed598a196d6ddf8d9c121e12e082cac3a
CVE-2019-14814 https://git.kernel.org/linus/7caac62ed598a196d6ddf8d9c121e12e082cac3a
CVE-2019-10126 https://git.kernel.org/linus/69ae4f6aac1578575126319d3f55550e7e440449
CVE-2019-9500  https://git.kernel.org/linus/1b5e2423164b3670e8bc9174e4762d297990deff
no-CVE-yet     https://git.kernel.org/linus/130f634da1af649205f4a3dd86cbe5c126b57914
no-CVE-yet     https://git.kernel.org/linus/d10a87a3535cce2b890897914f5d0d83df669c63

To accelerate the review of potential run-time false positives, it's
also worth noting that it is possible to partially automate checking
by examining the memcpy() buffer argument to check for the destination
struct member having a neighboring array member. It is reasonable to
expect that the vast majority of run-time false positives would look like
the already evaluated and fixed compile-time false positives, where the
most common pattern is neighboring arrays. (And, FWIW, several of the
compile-time fixes were actual bugs.)

Implementation:

Tighten the memcpy() destination buffer size checking to use the actual
("mode 1") target buffer size as the bounds check instead of their
enclosing structure's ("mode 0") size. Use a common inline for memcpy()
(and memmove() in a following patch), since all the tests are the
same. All new cross-field memcpy() uses must use the struct_group() macro
or similar to target a specific range of fields, so that FORTIFY_SOURCE
can reason about the size and safety of the copy.

For now, cross-member "mode 1" read detection at compile-time will be
limited to W=1 builds, since it is, unfortunately, very common. As the
priority is solving write overflows, read overflows can be part of the
next phase.

For run-time, the "mode 0" size checking and mitigation is left unchanged,
with "mode 1" to be added in stages. In this patch, no new run-time
checks are added. Future patches will first bounds-check writes,
and only perform a WARN() for now. This way any missed run-time false
positives can be flushed out over the coming several development cycles,
but system builders who have tested their workloads to be WARN()-free
can enable the panic_on_warn=1 sysctl to immediately gain a mitigation
against this class of buffer overflows. Once that is under way, run-time
bounds-checking of reads can be similarly added.

Related classes of flaws that remain unmitigated:

- memcpy() with raw pointers (e.g. void *, char *, etc) have no good
  mitigation beyond memory tagging (and even that would only protect
  against inter-object overflow, not intra-object neighboring field
  overflows). Some kind of "fat pointer" solution is likely needed to
  gain proper size-of-buffer awareness.

- type confusion where a higher level type's allocation size does
  not match the resulting cast type eventually passed to a deeper
  memcpy() call where the compiler cannot see the true type. In
  theory, greater static analysis could catch these.

[0] https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html
[1] https://git.kernel.org/linus/6a39e62abbafd1d58d1722f40c7d26ef379c6a2f

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/fortify-string.h                | 109 ++++++++++++++++--
 lib/Makefile                                  |   3 +-
 lib/string_helpers.c                          |   6 +
 .../read_overflow2_field-memcpy.c             |   5 +
 .../write_overflow_field-memcpy.c             |   5 +
 5 files changed, 115 insertions(+), 13 deletions(-)
 create mode 100644 lib/test_fortify/read_overflow2_field-memcpy.c
 create mode 100644 lib/test_fortify/write_overflow_field-memcpy.c

diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
index a6cd6815f249..132efa1ff49f 100644
--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -8,7 +8,9 @@
 void fortify_panic(const char *name) __noreturn __cold;
 void __read_overflow(void) __compiletime_error("detected read beyond size of object (1st parameter)");
 void __read_overflow2(void) __compiletime_error("detected read beyond size of object (2nd parameter)");
+void __read_overflow2_field(size_t avail, size_t wanted) __compiletime_warning("detected read beyond size of field (2nd parameter); maybe use struct_group()?");
 void __write_overflow(void) __compiletime_error("detected write beyond size of object (1st parameter)");
+void __write_overflow_field(size_t avail, size_t wanted) __compiletime_warning("detected write beyond size of field (1st parameter); maybe use struct_group()?");
 
 #define __compiletime_strlen(p)					\
 ({								\
@@ -209,22 +211,105 @@ __FORTIFY_INLINE void *memset(void *p, int c, __kernel_size_t size)
 	return __underlying_memset(p, c, size);
 }
 
-__FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
+/*
+ * To make sure the compiler can enforce protection against buffer overflows,
+ * memcpy(), memmove(), and memset() must not be used beyond individual
+ * struct members. If you need to copy across multiple members, please use
+ * struct_group() to create a named mirror of an anonymous struct union.
+ * (e.g. see struct sk_buff.)
+ *
+ * Mitigation coverage
+ *					Bounds checking at:
+ *					+-------+-------+-------+-------+
+ *					| Compile time  | Run time      |
+ * memcpy() argument sizes:		| write | read  | write | read  |
+ *					+-------+-------+-------+-------+
+ * memcpy(known,   known,   constant)	|   y   |   y   |  n/a  |  n/a  |
+ * memcpy(unknown, known,   constant)	|   n   |   y   |   V   |  n/a  |
+ * memcpy(known,   unknown, constant)	|   y   |   n   |  n/a  |   V   |
+ * memcpy(unknown, unknown, constant)	|   n   |   n   |   V   |   V   |
+ * memcpy(known,   known,   dynamic)	|   n   |   n   |   b   |   B   |
+ * memcpy(unknown, known,   dynamic)	|   n   |   n   |   V   |   B   |
+ * memcpy(known,   unknown, dynamic)	|   n   |   n   |   b   |   V   |
+ * memcpy(unknown, unknown, dynamic)	|   n   |   n   |   V   |   V   |
+ *					+-------+-------+-------+-------+
+ *
+ * y = deterministic compile-time bounds checking
+ * n = cannot do deterministic compile-time bounds checking
+ * n/a = no run-time bounds checking needed since compile-time deterministic
+ * b = perform run-time bounds checking
+ * B = can perform run-time bounds checking, but current unenforced
+ * V = vulnerable to run-time overflow
+ *
+ */
+__FORTIFY_INLINE void fortify_memcpy_chk(__kernel_size_t size,
+					 const size_t p_size,
+					 const size_t q_size,
+					 const size_t p_size_field,
+					 const size_t q_size_field,
+					 const char *func)
 {
-	size_t p_size = __builtin_object_size(p, 0);
-	size_t q_size = __builtin_object_size(q, 0);
-
 	if (__builtin_constant_p(size)) {
-		if (p_size < size)
+		/*
+		 * Length argument is a constant expression, so we
+		 * can perform compile-time bounds checking where
+		 * buffer sizes are known.
+		 */
+
+		/* Error when size is larger than enclosing struct. */
+		if (p_size > p_size_field && p_size < size)
 			__write_overflow();
-		if (q_size < size)
+		if (q_size > q_size_field && q_size < size)
 			__read_overflow2();
+
+		/* Warn when write size argument larger than dest field. */
+		if (p_size_field < size)
+			__write_overflow_field(p_size_field, size);
+		/*
+		 * Warn for source field over-read when building with W=1
+		 * or when an over-write happened, so both can be fixed at
+		 * the same time.
+		 */
+		if ((IS_ENABLED(KBUILD_EXTRA_WARN1) || p_size_field < size) &&
+		    q_size_field < size)
+			__read_overflow2_field(q_size_field, size);
 	}
-	if (p_size < size || q_size < size)
-		fortify_panic(__func__);
-	return __underlying_memcpy(p, q, size);
+	/*
+	 * At this point, length argument may not be a constant expression,
+	 * so run-time bounds checking can be done where buffer sizes are
+	 * known. (This is not an "else" because the above checks may only
+	 * be compile-time warnings, and we want to still warn for run-time
+	 * overflows.)
+	 */
+
+	/*
+	 * Always stop accesses beyond the struct that contains the
+	 * field, when the buffer's remaining size is known.
+	 * (The -1 test is to optimize away checks where the buffer
+	 * lengths are unknown.)
+	 */
+	if ((p_size != (size_t)(-1) && p_size < size) ||
+	    (q_size != (size_t)(-1) && q_size < size))
+		fortify_panic(func);
 }
 
+#define __fortify_memcpy_chk(p, q, size, p_size, q_size,		\
+			     p_size_field, q_size_field, op) ({		\
+	size_t __fortify_size = (size_t)(size);				\
+	fortify_memcpy_chk(__fortify_size, p_size, q_size,		\
+			   p_size_field, q_size_field, #op);		\
+	__underlying_##op(p, q, __fortify_size);			\
+})
+
+/*
+ * __builtin_object_size() must be captured here to avoid evaluating argument
+ * side-effects further into the macro layers.
+ */
+#define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,			\
+		__builtin_object_size(p, 0), __builtin_object_size(q, 0), \
+		__builtin_object_size(p, 1), __builtin_object_size(q, 1), \
+		memcpy)
+
 __FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size)
 {
 	size_t p_size = __builtin_object_size(p, 0);
@@ -304,13 +389,14 @@ __FORTIFY_INLINE void *kmemdup(const void *p, size_t size, gfp_t gfp)
 	return __real_kmemdup(p, size, gfp);
 }
 
-/* defined after fortified strlen and memcpy to reuse them */
+/* Defined after fortified strlen to reuse it. */
 __FORTIFY_INLINE char *strcpy(char *p, const char *q)
 {
 	size_t p_size = __builtin_object_size(p, 1);
 	size_t q_size = __builtin_object_size(q, 1);
 	size_t size;
 
+	/* If neither buffer size is known, immediately give up. */
 	if (p_size == (size_t)-1 && q_size == (size_t)-1)
 		return __underlying_strcpy(p, q);
 	size = strlen(q) + 1;
@@ -320,14 +406,13 @@ __FORTIFY_INLINE char *strcpy(char *p, const char *q)
 	/* Run-time check for dynamic size overflow. */
 	if (p_size < size)
 		fortify_panic(__func__);
-	memcpy(p, q, size);
+	__underlying_memcpy(p, q, size);
 	return p;
 }
 
 /* Don't use these outside the FORITFY_SOURCE implementation */
 #undef __underlying_memchr
 #undef __underlying_memcmp
-#undef __underlying_memcpy
 #undef __underlying_memmove
 #undef __underlying_memset
 #undef __underlying_strcat
diff --git a/lib/Makefile b/lib/Makefile
index b213a7bbf3fd..7ea43029431b 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -373,7 +373,8 @@ TEST_FORTIFY_LOG = test_fortify.log
 quiet_cmd_test_fortify = TEST    $@
       cmd_test_fortify = $(CONFIG_SHELL) $(srctree)/scripts/test_fortify.sh \
 			$< $@ "$(NM)" $(CC) $(c_flags) \
-			$(call cc-disable-warning,fortify-source)
+			$(call cc-disable-warning,fortify-source) \
+			-DKBUILD_EXTRA_WARN1
 
 targets += $(TEST_FORTIFY_LOGS)
 clean-files += $(TEST_FORTIFY_LOGS)
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 90f9f1b7afec..4f877e9551d5 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -968,6 +968,12 @@ void memcpy_and_pad(void *dest, size_t dest_len, const void *src, size_t count,
 EXPORT_SYMBOL(memcpy_and_pad);
 
 #ifdef CONFIG_FORTIFY_SOURCE
+/* These are placeholders for fortify compile-time warnings. */
+void __read_overflow2_field(size_t avail, size_t wanted) { }
+EXPORT_SYMBOL(__read_overflow2_field);
+void __write_overflow_field(size_t avail, size_t wanted) { }
+EXPORT_SYMBOL(__write_overflow_field);
+
 void fortify_panic(const char *name)
 {
 	pr_emerg("detected buffer overflow in %s\n", name);
diff --git a/lib/test_fortify/read_overflow2_field-memcpy.c b/lib/test_fortify/read_overflow2_field-memcpy.c
new file mode 100644
index 000000000000..de9569266223
--- /dev/null
+++ b/lib/test_fortify/read_overflow2_field-memcpy.c
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#define TEST	\
+	memcpy(large, instance.buf, sizeof(instance.buf) + 1)
+
+#include "test_fortify.h"
diff --git a/lib/test_fortify/write_overflow_field-memcpy.c b/lib/test_fortify/write_overflow_field-memcpy.c
new file mode 100644
index 000000000000..28cc81058dd3
--- /dev/null
+++ b/lib/test_fortify/write_overflow_field-memcpy.c
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#define TEST	\
+	memcpy(instance.buf, large, sizeof(instance.buf) + 1)
+
+#include "test_fortify.h"
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 07/17] fortify: Detect struct member overflows in memmove() at compile-time
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (5 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33   ` Kees Cook
                   ` (11 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, linux-kernel

As done for memcpy(), also update memmove() to use the same tightened
compile-time checks under CONFIG_FORTIFY_SOURCE.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 arch/x86/boot/compressed/misc.c               |  3 ++-
 arch/x86/lib/memcpy_32.c                      |  1 +
 include/linux/fortify-string.h                | 21 ++++---------------
 .../read_overflow2_field-memmove.c            |  5 +++++
 .../write_overflow_field-memmove.c            |  5 +++++
 5 files changed, 17 insertions(+), 18 deletions(-)
 create mode 100644 lib/test_fortify/read_overflow2_field-memmove.c
 create mode 100644 lib/test_fortify/write_overflow_field-memmove.c

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index a4339cb2d247..1cdcaf34ee36 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -37,10 +37,11 @@
  * try to define their own functions if these are not defined as macros.
  */
 #define memzero(s, n)	memset((s), 0, (n))
+#ifndef memmove
 #define memmove		memmove
-
 /* Functions used by the included decompressor code below. */
 void *memmove(void *dest, const void *src, size_t n);
+#endif
 
 /*
  * This is set up by the setup-routine at boot-time
diff --git a/arch/x86/lib/memcpy_32.c b/arch/x86/lib/memcpy_32.c
index e565d1c9019e..f19b7fd07f04 100644
--- a/arch/x86/lib/memcpy_32.c
+++ b/arch/x86/lib/memcpy_32.c
@@ -4,6 +4,7 @@
 
 #undef memcpy
 #undef memset
+#undef memmove
 
 __visible void *memcpy(void *to, const void *from, size_t n)
 {
diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
index 132efa1ff49f..c07871a3fcd0 100644
--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -309,22 +309,10 @@ __FORTIFY_INLINE void fortify_memcpy_chk(__kernel_size_t size,
 		__builtin_object_size(p, 0), __builtin_object_size(q, 0), \
 		__builtin_object_size(p, 1), __builtin_object_size(q, 1), \
 		memcpy)
-
-__FORTIFY_INLINE void *memmove(void *p, const void *q, __kernel_size_t size)
-{
-	size_t p_size = __builtin_object_size(p, 0);
-	size_t q_size = __builtin_object_size(q, 0);
-
-	if (__builtin_constant_p(size)) {
-		if (p_size < size)
-			__write_overflow();
-		if (q_size < size)
-			__read_overflow2();
-	}
-	if (p_size < size || q_size < size)
-		fortify_panic(__func__);
-	return __underlying_memmove(p, q, size);
-}
+#define memmove(p, q, s)  __fortify_memcpy_chk(p, q, s,			\
+		__builtin_object_size(p, 0), __builtin_object_size(q, 0), \
+		__builtin_object_size(p, 1), __builtin_object_size(q, 1), \
+		memmove)
 
 extern void *__real_memscan(void *, int, __kernel_size_t) __RENAME(memscan);
 __FORTIFY_INLINE void *memscan(void *p, int c, __kernel_size_t size)
@@ -413,7 +401,6 @@ __FORTIFY_INLINE char *strcpy(char *p, const char *q)
 /* Don't use these outside the FORITFY_SOURCE implementation */
 #undef __underlying_memchr
 #undef __underlying_memcmp
-#undef __underlying_memmove
 #undef __underlying_memset
 #undef __underlying_strcat
 #undef __underlying_strcpy
diff --git a/lib/test_fortify/read_overflow2_field-memmove.c b/lib/test_fortify/read_overflow2_field-memmove.c
new file mode 100644
index 000000000000..6cc2724c8f62
--- /dev/null
+++ b/lib/test_fortify/read_overflow2_field-memmove.c
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#define TEST	\
+	memmove(large, instance.buf, sizeof(instance.buf) + 1)
+
+#include "test_fortify.h"
diff --git a/lib/test_fortify/write_overflow_field-memmove.c b/lib/test_fortify/write_overflow_field-memmove.c
new file mode 100644
index 000000000000..377fcf9bb2fd
--- /dev/null
+++ b/lib/test_fortify/write_overflow_field-memmove.c
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#define TEST	\
+	memmove(instance.buf, large, sizeof(instance.buf) + 1)
+
+#include "test_fortify.h"
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
@ 2021-12-13 22:33   ` Kees Cook
  2021-12-13 22:33 ` [PATCH 02/17] net/mlx5e: Avoid field-overflowing memcpy() Kees Cook
                     ` (17 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Kalle Valo, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Use memset_startat() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct. Additionally split up a later
field-spanning memset() so that memset() can reason about the size.

Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: ath11k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/net/wireless/ath/ath11k/hal_rx.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
index 329c404cfa80..0e43e215c10a 100644
--- a/drivers/net/wireless/ath/ath11k/hal_rx.c
+++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
@@ -29,8 +29,7 @@ static int ath11k_hal_reo_cmd_queue_stats(struct hal_tlv_hdr *tlv,
 		  FIELD_PREP(HAL_TLV_HDR_LEN, sizeof(*desc));
 
 	desc = (struct hal_reo_get_queue_stats *)tlv->value;
-	memset(&desc->queue_addr_lo, 0,
-	       (sizeof(*desc) - sizeof(struct hal_reo_cmd_hdr)));
+	memset_startat(desc, 0, queue_addr_lo);
 
 	desc->cmd.info0 &= ~HAL_REO_CMD_HDR_INFO0_STATUS_REQUIRED;
 	if (cmd->flag & HAL_REO_CMD_FLG_NEED_STATUS)
@@ -62,8 +61,7 @@ static int ath11k_hal_reo_cmd_flush_cache(struct ath11k_hal *hal, struct hal_tlv
 		  FIELD_PREP(HAL_TLV_HDR_LEN, sizeof(*desc));
 
 	desc = (struct hal_reo_flush_cache *)tlv->value;
-	memset(&desc->cache_addr_lo, 0,
-	       (sizeof(*desc) - sizeof(struct hal_reo_cmd_hdr)));
+	memset_startat(desc, 0, cache_addr_lo);
 
 	desc->cmd.info0 &= ~HAL_REO_CMD_HDR_INFO0_STATUS_REQUIRED;
 	if (cmd->flag & HAL_REO_CMD_FLG_NEED_STATUS)
@@ -101,8 +99,7 @@ static int ath11k_hal_reo_cmd_update_rx_queue(struct hal_tlv_hdr *tlv,
 		  FIELD_PREP(HAL_TLV_HDR_LEN, sizeof(*desc));
 
 	desc = (struct hal_reo_update_rx_queue *)tlv->value;
-	memset(&desc->queue_addr_lo, 0,
-	       (sizeof(*desc) - sizeof(struct hal_reo_cmd_hdr)));
+	memset_startat(desc, 0, queue_addr_lo);
 
 	desc->cmd.info0 &= ~HAL_REO_CMD_HDR_INFO0_STATUS_REQUIRED;
 	if (cmd->flag & HAL_REO_CMD_FLG_NEED_STATUS)
@@ -764,15 +761,17 @@ void ath11k_hal_reo_qdesc_setup(void *vaddr, int tid, u32 ba_window_size,
 	 * size changes and also send WMI message to FW to change the REO
 	 * queue descriptor in Rx peer entry as part of dp_rx_tid_update.
 	 */
-	memset(ext_desc, 0, 3 * sizeof(*ext_desc));
+	memset(ext_desc, 0, sizeof(*ext_desc));
 	ath11k_hal_reo_set_desc_hdr(&ext_desc->desc_hdr, HAL_DESC_REO_OWNED,
 				    HAL_DESC_REO_QUEUE_EXT_DESC,
 				    REO_QUEUE_DESC_MAGIC_DEBUG_PATTERN_1);
 	ext_desc++;
+	memset(ext_desc, 0, sizeof(*ext_desc));
 	ath11k_hal_reo_set_desc_hdr(&ext_desc->desc_hdr, HAL_DESC_REO_OWNED,
 				    HAL_DESC_REO_QUEUE_EXT_DESC,
 				    REO_QUEUE_DESC_MAGIC_DEBUG_PATTERN_2);
 	ext_desc++;
+	memset(ext_desc, 0, sizeof(*ext_desc));
 	ath11k_hal_reo_set_desc_hdr(&ext_desc->desc_hdr, HAL_DESC_REO_OWNED,
 				    HAL_DESC_REO_QUEUE_EXT_DESC,
 				    REO_QUEUE_DESC_MAGIC_DEBUG_PATTERN_3);
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
@ 2021-12-13 22:33   ` Kees Cook
  0 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Kalle Valo, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Use memset_startat() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct. Additionally split up a later
field-spanning memset() so that memset() can reason about the size.

Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: ath11k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/net/wireless/ath/ath11k/hal_rx.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ath/ath11k/hal_rx.c b/drivers/net/wireless/ath/ath11k/hal_rx.c
index 329c404cfa80..0e43e215c10a 100644
--- a/drivers/net/wireless/ath/ath11k/hal_rx.c
+++ b/drivers/net/wireless/ath/ath11k/hal_rx.c
@@ -29,8 +29,7 @@ static int ath11k_hal_reo_cmd_queue_stats(struct hal_tlv_hdr *tlv,
 		  FIELD_PREP(HAL_TLV_HDR_LEN, sizeof(*desc));
 
 	desc = (struct hal_reo_get_queue_stats *)tlv->value;
-	memset(&desc->queue_addr_lo, 0,
-	       (sizeof(*desc) - sizeof(struct hal_reo_cmd_hdr)));
+	memset_startat(desc, 0, queue_addr_lo);
 
 	desc->cmd.info0 &= ~HAL_REO_CMD_HDR_INFO0_STATUS_REQUIRED;
 	if (cmd->flag & HAL_REO_CMD_FLG_NEED_STATUS)
@@ -62,8 +61,7 @@ static int ath11k_hal_reo_cmd_flush_cache(struct ath11k_hal *hal, struct hal_tlv
 		  FIELD_PREP(HAL_TLV_HDR_LEN, sizeof(*desc));
 
 	desc = (struct hal_reo_flush_cache *)tlv->value;
-	memset(&desc->cache_addr_lo, 0,
-	       (sizeof(*desc) - sizeof(struct hal_reo_cmd_hdr)));
+	memset_startat(desc, 0, cache_addr_lo);
 
 	desc->cmd.info0 &= ~HAL_REO_CMD_HDR_INFO0_STATUS_REQUIRED;
 	if (cmd->flag & HAL_REO_CMD_FLG_NEED_STATUS)
@@ -101,8 +99,7 @@ static int ath11k_hal_reo_cmd_update_rx_queue(struct hal_tlv_hdr *tlv,
 		  FIELD_PREP(HAL_TLV_HDR_LEN, sizeof(*desc));
 
 	desc = (struct hal_reo_update_rx_queue *)tlv->value;
-	memset(&desc->queue_addr_lo, 0,
-	       (sizeof(*desc) - sizeof(struct hal_reo_cmd_hdr)));
+	memset_startat(desc, 0, queue_addr_lo);
 
 	desc->cmd.info0 &= ~HAL_REO_CMD_HDR_INFO0_STATUS_REQUIRED;
 	if (cmd->flag & HAL_REO_CMD_FLG_NEED_STATUS)
@@ -764,15 +761,17 @@ void ath11k_hal_reo_qdesc_setup(void *vaddr, int tid, u32 ba_window_size,
 	 * size changes and also send WMI message to FW to change the REO
 	 * queue descriptor in Rx peer entry as part of dp_rx_tid_update.
 	 */
-	memset(ext_desc, 0, 3 * sizeof(*ext_desc));
+	memset(ext_desc, 0, sizeof(*ext_desc));
 	ath11k_hal_reo_set_desc_hdr(&ext_desc->desc_hdr, HAL_DESC_REO_OWNED,
 				    HAL_DESC_REO_QUEUE_EXT_DESC,
 				    REO_QUEUE_DESC_MAGIC_DEBUG_PATTERN_1);
 	ext_desc++;
+	memset(ext_desc, 0, sizeof(*ext_desc));
 	ath11k_hal_reo_set_desc_hdr(&ext_desc->desc_hdr, HAL_DESC_REO_OWNED,
 				    HAL_DESC_REO_QUEUE_EXT_DESC,
 				    REO_QUEUE_DESC_MAGIC_DEBUG_PATTERN_2);
 	ext_desc++;
+	memset(ext_desc, 0, sizeof(*ext_desc));
 	ath11k_hal_reo_set_desc_hdr(&ext_desc->desc_hdr, HAL_DESC_REO_OWNED,
 				    HAL_DESC_REO_QUEUE_EXT_DESC,
 				    REO_QUEUE_DESC_MAGIC_DEBUG_PATTERN_3);
-- 
2.30.2


-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 09/17] RDMA/mlx5: Use memset_after() to zero struct mlx5_ib_mr
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (7 preceding siblings ...)
  2021-12-13 22:33   ` Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 10/17] drbd: Use struct_group() to zero algs Kees Cook
                   ` (9 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Doug Ledford, Jason Gunthorpe, linux-rdma,
	Leon Romanovsky, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Use memset_after() to zero the end of struct mlx5_ib_mr that should
be initialized.

Cc: Doug Ledford <dledford@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-rdma@vger.kernel.org
Acked-by: Leon Romanovsky <leonro@nvidia.com>
Link: https://lore.kernel.org/lkml/YbByJSkBgLRp5S8V@unreal
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/infiniband/hw/mlx5/mlx5_ib.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index 4a7a56ed740b..ded10719b643 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -664,8 +664,8 @@ struct mlx5_ib_mr {
 
 	/* User MR data */
 	struct mlx5_cache_ent *cache_ent;
+	/* Everything after cache_ent is zero'd when MR allocated */
 
-	/* This is zero'd when the MR is allocated */
 	union {
 		/* Used only while the MR is in the cache */
 		struct {
@@ -718,7 +718,7 @@ struct mlx5_ib_mr {
 /* Zero the fields in the mr that are variant depending on usage */
 static inline void mlx5_clear_mr(struct mlx5_ib_mr *mr)
 {
-	memset(mr->out, 0, sizeof(*mr) - offsetof(struct mlx5_ib_mr, out));
+	memset_after(mr, 0, cache_ent);
 }
 
 static inline bool is_odp_mr(struct mlx5_ib_mr *mr)
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 10/17] drbd: Use struct_group() to zero algs
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (8 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 09/17] RDMA/mlx5: Use memset_after() to zero struct mlx5_ib_mr Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33   ` [dm-devel] " Kees Cook
                   ` (8 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Philipp Reisner, Lars Ellenberg, Jens Axboe, drbd-dev,
	linux-block, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Add a struct_group() for the algs so that memset() can correctly reason
about the size. "objdump -d" shows no changes to the executable
instructions.

Cc: Philipp Reisner <philipp.reisner@linbit.com>
Cc: Lars Ellenberg <lars.ellenberg@linbit.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: drbd-dev@lists.linbit.com
Cc: linux-block@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/block/drbd/drbd_main.c     | 3 ++-
 drivers/block/drbd/drbd_protocol.h | 6 ++++--
 drivers/block/drbd/drbd_receiver.c | 3 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 07b3c6093e7d..6f450816c4fa 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -729,7 +729,8 @@ int drbd_send_sync_param(struct drbd_peer_device *peer_device)
 	cmd = apv >= 89 ? P_SYNC_PARAM89 : P_SYNC_PARAM;
 
 	/* initialize verify_alg and csums_alg */
-	memset(p->verify_alg, 0, 2 * SHARED_SECRET_MAX);
+	BUILD_BUG_ON(sizeof(p->algs) != 2 * SHARED_SECRET_MAX);
+	memset(&p->algs, 0, sizeof(p->algs));
 
 	if (get_ldev(peer_device->device)) {
 		dc = rcu_dereference(peer_device->device->ldev->disk_conf);
diff --git a/drivers/block/drbd/drbd_protocol.h b/drivers/block/drbd/drbd_protocol.h
index dea59c92ecc1..a882b65ab5d2 100644
--- a/drivers/block/drbd/drbd_protocol.h
+++ b/drivers/block/drbd/drbd_protocol.h
@@ -283,8 +283,10 @@ struct p_rs_param_89 {
 
 struct p_rs_param_95 {
 	u32 resync_rate;
-	char verify_alg[SHARED_SECRET_MAX];
-	char csums_alg[SHARED_SECRET_MAX];
+	struct_group(algs,
+		char verify_alg[SHARED_SECRET_MAX];
+		char csums_alg[SHARED_SECRET_MAX];
+	);
 	u32 c_plan_ahead;
 	u32 c_delay_target;
 	u32 c_fill_target;
diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c
index 1f740e42e457..6df2539e215b 100644
--- a/drivers/block/drbd/drbd_receiver.c
+++ b/drivers/block/drbd/drbd_receiver.c
@@ -3921,7 +3921,8 @@ static int receive_SyncParam(struct drbd_connection *connection, struct packet_i
 
 	/* initialize verify_alg and csums_alg */
 	p = pi->data;
-	memset(p->verify_alg, 0, 2 * SHARED_SECRET_MAX);
+	BUILD_BUG_ON(sizeof(p->algs) != 2 * SHARED_SECRET_MAX);
+	memset(&p->algs, 0, sizeof(p->algs));
 
 	err = drbd_recv_all(peer_device->connection, p, header_size);
 	if (err)
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 11/17] dm integrity: Use struct_group() to zero struct journal_sector
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
@ 2021-12-13 22:33   ` Kees Cook
  2021-12-13 22:33 ` [PATCH 02/17] net/mlx5e: Avoid field-overflowing memcpy() Kees Cook
                     ` (17 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Alasdair Kergon, Mike Snitzer, dm-devel, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Add struct_group() to mark region of struct journal_sector that should be
initialized to zero.

Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/md/dm-integrity.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 6319deccbe09..163c94ca4e5c 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -121,8 +121,10 @@ struct journal_entry {
 #define JOURNAL_MAC_SIZE		(JOURNAL_MAC_PER_SECTOR * JOURNAL_BLOCK_SECTORS)
 
 struct journal_sector {
-	__u8 entries[JOURNAL_SECTOR_DATA - JOURNAL_MAC_PER_SECTOR];
-	__u8 mac[JOURNAL_MAC_PER_SECTOR];
+	struct_group(sectors,
+		__u8 entries[JOURNAL_SECTOR_DATA - JOURNAL_MAC_PER_SECTOR];
+		__u8 mac[JOURNAL_MAC_PER_SECTOR];
+	);
 	commit_id_t commit_id;
 };
 
@@ -2870,7 +2872,8 @@ static void init_journal(struct dm_integrity_c *ic, unsigned start_section,
 		wraparound_section(ic, &i);
 		for (j = 0; j < ic->journal_section_sectors; j++) {
 			struct journal_sector *js = access_journal(ic, i, j);
-			memset(&js->entries, 0, JOURNAL_SECTOR_DATA);
+			BUILD_BUG_ON(sizeof(js->sectors) != JOURNAL_SECTOR_DATA);
+			memset(&js->sectors, 0, sizeof(js->sectors));
 			js->commit_id = dm_integrity_commit_id(ic, i, j, commit_seq);
 		}
 		for (j = 0; j < ic->journal_section_entries; j++) {
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [dm-devel] [PATCH 11/17] dm integrity: Use struct_group() to zero struct journal_sector
@ 2021-12-13 22:33   ` Kees Cook
  0 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Mike Snitzer, dm-devel, Kees Cook, Alasdair Kergon, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Add struct_group() to mark region of struct journal_sector that should be
initialized to zero.

Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/md/dm-integrity.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index 6319deccbe09..163c94ca4e5c 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -121,8 +121,10 @@ struct journal_entry {
 #define JOURNAL_MAC_SIZE		(JOURNAL_MAC_PER_SECTOR * JOURNAL_BLOCK_SECTORS)
 
 struct journal_sector {
-	__u8 entries[JOURNAL_SECTOR_DATA - JOURNAL_MAC_PER_SECTOR];
-	__u8 mac[JOURNAL_MAC_PER_SECTOR];
+	struct_group(sectors,
+		__u8 entries[JOURNAL_SECTOR_DATA - JOURNAL_MAC_PER_SECTOR];
+		__u8 mac[JOURNAL_MAC_PER_SECTOR];
+	);
 	commit_id_t commit_id;
 };
 
@@ -2870,7 +2872,8 @@ static void init_journal(struct dm_integrity_c *ic, unsigned start_section,
 		wraparound_section(ic, &i);
 		for (j = 0; j < ic->journal_section_sectors; j++) {
 			struct journal_sector *js = access_journal(ic, i, j);
-			memset(&js->entries, 0, JOURNAL_SECTOR_DATA);
+			BUILD_BUG_ON(sizeof(js->sectors) != JOURNAL_SECTOR_DATA);
+			memset(&js->sectors, 0, sizeof(js->sectors));
 			js->commit_id = dm_integrity_commit_id(ic, i, j, commit_seq);
 		}
 		for (j = 0; j < ic->journal_section_entries; j++) {
-- 
2.30.2

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 12/17] iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (10 preceding siblings ...)
  2021-12-13 22:33   ` [dm-devel] " Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 13/17] intel_th: msu: Use memset_startat() for clearing hw header Kees Cook
                   ` (6 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Potnuri Bharat Teja, Doug Ledford, Jason Gunthorpe,
	Raju Rangoju, David S. Miller, Jakub Kicinski, linux-rdma,
	netdev, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Use memset_startat() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct. Additionally, since everything
appears to perform a roundup (including allocation), just change the
size of the struct itself and add a build-time check to validate the
expected size.

Cc: Potnuri Bharat Teja <bharat@chelsio.com>
Cc: Doug Ledford <dledford@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Raju Rangoju <rajur@chelsio.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: linux-rdma@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/infiniband/hw/cxgb4/cm.c            | 5 +++--
 drivers/net/ethernet/chelsio/cxgb4/t4_msg.h | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index 913f39ee4416..c16017f6e8db 100644
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -2471,7 +2471,8 @@ static int accept_cr(struct c4iw_ep *ep, struct sk_buff *skb,
 	skb_get(skb);
 	rpl = cplhdr(skb);
 	if (!is_t4(adapter_type)) {
-		skb_trim(skb, roundup(sizeof(*rpl5), 16));
+		BUILD_BUG_ON(sizeof(*rpl5) != roundup(sizeof(*rpl5), 16));
+		skb_trim(skb, sizeof(*rpl5));
 		rpl5 = (void *)rpl;
 		INIT_TP_WR(rpl5, ep->hwtid);
 	} else {
@@ -2487,7 +2488,7 @@ static int accept_cr(struct c4iw_ep *ep, struct sk_buff *skb,
 		opt2 |= CONG_CNTRL_V(CONG_ALG_TAHOE);
 		opt2 |= T5_ISS_F;
 		rpl5 = (void *)rpl;
-		memset(&rpl5->iss, 0, roundup(sizeof(*rpl5)-sizeof(*rpl), 16));
+		memset_after(rpl5, 0, iss);
 		if (peer2peer)
 			isn += 4;
 		rpl5->iss = cpu_to_be32(isn);
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
index fed5f93bf620..26433a62d7f0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_msg.h
@@ -497,7 +497,7 @@ struct cpl_t5_pass_accept_rpl {
 	__be32 opt2;
 	__be64 opt0;
 	__be32 iss;
-	__be32 rsvd;
+	__be32 rsvd[3];
 };
 
 struct cpl_act_open_req {
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 13/17] intel_th: msu: Use memset_startat() for clearing hw header
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (11 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 12/17] iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 14/17] IB/mthca: Use memset_startat() for clearing mpt_entry Kees Cook
                   ` (5 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, Alexander Shishkin, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Use memset_startat() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct.

Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Link: https://lore.kernel.org/lkml/87sfyzi97l.fsf@ashishki-desk.ger.corp.intel.com
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/hwtracing/intel_th/msu.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/hwtracing/intel_th/msu.c b/drivers/hwtracing/intel_th/msu.c
index 432ade0842f6..70a07b4e9967 100644
--- a/drivers/hwtracing/intel_th/msu.c
+++ b/drivers/hwtracing/intel_th/msu.c
@@ -658,13 +658,11 @@ static void msc_buffer_clear_hw_header(struct msc *msc)
 
 	list_for_each_entry(win, &msc->win_list, entry) {
 		unsigned int blk;
-		size_t hw_sz = sizeof(struct msc_block_desc) -
-			offsetof(struct msc_block_desc, hw_tag);
 
 		for_each_sg(win->sgt->sgl, sg, win->nr_segs, blk) {
 			struct msc_block_desc *bdesc = sg_virt(sg);
 
-			memset(&bdesc->hw_tag, 0, hw_sz);
+			memset_startat(bdesc, 0, hw_tag);
 		}
 	}
 }
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 14/17] IB/mthca: Use memset_startat() for clearing mpt_entry
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (12 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 13/17] intel_th: msu: Use memset_startat() for clearing hw header Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 15/17] scsi: lpfc: Use struct_group() to initialize struct lpfc_cgn_info Kees Cook
                   ` (4 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, Doug Ledford, Jason Gunthorpe, Max Gurtovoy,
	linux-rdma, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Use memset_startat() so memset() doesn't get confused about writing
beyond the destination member that is intended to be the starting point
of zeroing through the end of the struct.

Cc: Doug Ledford <dledford@redhat.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Max Gurtovoy <maxg@mellanox.com>
Cc: linux-rdma@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/infiniband/hw/mthca/mthca_mr.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/mthca/mthca_mr.c b/drivers/infiniband/hw/mthca/mthca_mr.c
index a59100c496b4..192f83fd7c8a 100644
--- a/drivers/infiniband/hw/mthca/mthca_mr.c
+++ b/drivers/infiniband/hw/mthca/mthca_mr.c
@@ -467,8 +467,7 @@ int mthca_mr_alloc(struct mthca_dev *dev, u32 pd, int buffer_size_shift,
 	mpt_entry->start     = cpu_to_be64(iova);
 	mpt_entry->length    = cpu_to_be64(total_size);
 
-	memset(&mpt_entry->lkey, 0,
-	       sizeof *mpt_entry - offsetof(struct mthca_mpt_entry, lkey));
+	memset_startat(mpt_entry, 0, lkey);
 
 	if (mr->mtt)
 		mpt_entry->mtt_seg =
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 15/17] scsi: lpfc: Use struct_group() to initialize struct lpfc_cgn_info
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (13 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 14/17] IB/mthca: Use memset_startat() for clearing mpt_entry Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-13 22:33 ` [PATCH 16/17] fortify: Detect struct member overflows in memset() at compile-time Kees Cook
                   ` (3 subsequent siblings)
  18 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening
  Cc: Kees Cook, James Smart, Dick Kennedy, James E.J. Bottomley,
	Martin K. Petersen, linux-scsi, linux-kernel

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memset(), avoid intentionally writing across
neighboring fields.

Add struct_group() to mark "stat" region of struct lpfc_cgn_info that
should be initialized to zero, and refactor the "data" region memset()
to wipe everything up to the cgn_stats region.

Cc: James Smart <james.smart@broadcom.com>
Cc: Dick Kennedy <dick.kennedy@broadcom.com>
Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 drivers/scsi/lpfc/lpfc.h      | 90 +++++++++++++++++------------------
 drivers/scsi/lpfc/lpfc_init.c |  4 +-
 2 files changed, 46 insertions(+), 48 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 3faadcfcdcbb..4878c94761f9 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -496,52 +496,50 @@ struct lpfc_cgn_info {
 	__le32   cgn_alarm_hr[24];
 	__le32   cgn_alarm_day[LPFC_MAX_CGN_DAYS];
 
-	/* Start of congestion statistics */
-	uint8_t  cgn_stat_npm;		/* Notifications per minute */
-
-	/* Start Time */
-	uint8_t  cgn_stat_month;
-	uint8_t  cgn_stat_day;
-	uint8_t  cgn_stat_year;
-	uint8_t  cgn_stat_hour;
-	uint8_t  cgn_stat_minute;
-	uint8_t  cgn_pad2[2];
-
-	__le32   cgn_notification;
-	__le32   cgn_peer_notification;
-	__le32   link_integ_notification;
-	__le32   delivery_notification;
-
-	uint8_t  cgn_stat_cgn_month; /* Last congestion notification FPIN */
-	uint8_t  cgn_stat_cgn_day;
-	uint8_t  cgn_stat_cgn_year;
-	uint8_t  cgn_stat_cgn_hour;
-	uint8_t  cgn_stat_cgn_min;
-	uint8_t  cgn_stat_cgn_sec;
-
-	uint8_t  cgn_stat_peer_month; /* Last peer congestion FPIN */
-	uint8_t  cgn_stat_peer_day;
-	uint8_t  cgn_stat_peer_year;
-	uint8_t  cgn_stat_peer_hour;
-	uint8_t  cgn_stat_peer_min;
-	uint8_t  cgn_stat_peer_sec;
-
-	uint8_t  cgn_stat_lnk_month; /* Last link integrity FPIN */
-	uint8_t  cgn_stat_lnk_day;
-	uint8_t  cgn_stat_lnk_year;
-	uint8_t  cgn_stat_lnk_hour;
-	uint8_t  cgn_stat_lnk_min;
-	uint8_t  cgn_stat_lnk_sec;
-
-	uint8_t  cgn_stat_del_month; /* Last delivery notification FPIN */
-	uint8_t  cgn_stat_del_day;
-	uint8_t  cgn_stat_del_year;
-	uint8_t  cgn_stat_del_hour;
-	uint8_t  cgn_stat_del_min;
-	uint8_t  cgn_stat_del_sec;
-#define LPFC_CGN_STAT_SIZE	48
-#define LPFC_CGN_DATA_SIZE	(sizeof(struct lpfc_cgn_info) -  \
-				LPFC_CGN_STAT_SIZE - sizeof(uint32_t))
+	struct_group(cgn_stat,
+		uint8_t  cgn_stat_npm;		/* Notifications per minute */
+
+		/* Start Time */
+		uint8_t  cgn_stat_month;
+		uint8_t  cgn_stat_day;
+		uint8_t  cgn_stat_year;
+		uint8_t  cgn_stat_hour;
+		uint8_t  cgn_stat_minute;
+		uint8_t  cgn_pad2[2];
+
+		__le32   cgn_notification;
+		__le32   cgn_peer_notification;
+		__le32   link_integ_notification;
+		__le32   delivery_notification;
+
+		uint8_t  cgn_stat_cgn_month; /* Last congestion notification FPIN */
+		uint8_t  cgn_stat_cgn_day;
+		uint8_t  cgn_stat_cgn_year;
+		uint8_t  cgn_stat_cgn_hour;
+		uint8_t  cgn_stat_cgn_min;
+		uint8_t  cgn_stat_cgn_sec;
+
+		uint8_t  cgn_stat_peer_month; /* Last peer congestion FPIN */
+		uint8_t  cgn_stat_peer_day;
+		uint8_t  cgn_stat_peer_year;
+		uint8_t  cgn_stat_peer_hour;
+		uint8_t  cgn_stat_peer_min;
+		uint8_t  cgn_stat_peer_sec;
+
+		uint8_t  cgn_stat_lnk_month; /* Last link integrity FPIN */
+		uint8_t  cgn_stat_lnk_day;
+		uint8_t  cgn_stat_lnk_year;
+		uint8_t  cgn_stat_lnk_hour;
+		uint8_t  cgn_stat_lnk_min;
+		uint8_t  cgn_stat_lnk_sec;
+
+		uint8_t  cgn_stat_del_month; /* Last delivery notification FPIN */
+		uint8_t  cgn_stat_del_day;
+		uint8_t  cgn_stat_del_year;
+		uint8_t  cgn_stat_del_hour;
+		uint8_t  cgn_stat_del_min;
+		uint8_t  cgn_stat_del_sec;
+	);
 
 	__le32   cgn_info_crc;
 #define LPFC_CGN_CRC32_MAGIC_NUMBER	0x1EDC6F41
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 2fe7d9d885d9..c18000d05379 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -13483,7 +13483,7 @@ lpfc_init_congestion_buf(struct lpfc_hba *phba)
 	phba->cgn_evt_minute = 0;
 	phba->hba_flag &= ~HBA_CGN_DAY_WRAP;
 
-	memset(cp, 0xff, LPFC_CGN_DATA_SIZE);
+	memset(cp, 0xff, offsetof(struct lpfc_cgn_info, cgn_stat));
 	cp->cgn_info_size = cpu_to_le16(LPFC_CGN_INFO_SZ);
 	cp->cgn_info_version = LPFC_CGN_INFO_V3;
 
@@ -13542,7 +13542,7 @@ lpfc_init_congestion_stat(struct lpfc_hba *phba)
 		return;
 
 	cp = (struct lpfc_cgn_info *)phba->cgn_i->virt;
-	memset(&cp->cgn_stat_npm, 0, LPFC_CGN_STAT_SIZE);
+	memset(&cp->cgn_stat, 0, sizeof(cp->cgn_stat));
 
 	ktime_get_real_ts64(&cmpl_time);
 	time64_to_tm(cmpl_time.tv_sec, 0, &broken);
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 16/17] fortify: Detect struct member overflows in memset() at compile-time
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (14 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 15/17] scsi: lpfc: Use struct_group() to initialize struct lpfc_cgn_info Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-14 12:31   ` kernel test robot
  2021-12-13 22:33 ` [PATCH 17/17] fortify: Work around Clang inlining bugs Kees Cook
                   ` (2 subsequent siblings)
  18 siblings, 1 reply; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, linux-kernel

As done for memcpy(), also update memset() to use the same tightened
compile-time bounds checking under CONFIG_FORTIFY_SOURCE.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/fortify-string.h                | 54 ++++++++++++++++---
 .../write_overflow_field-memset.c             |  5 ++
 2 files changed, 51 insertions(+), 8 deletions(-)
 create mode 100644 lib/test_fortify/write_overflow_field-memset.c

diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
index c07871a3fcd0..c45159dbdaa1 100644
--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -200,17 +200,56 @@ __FORTIFY_INLINE char *strncat(char *p, const char *q, __kernel_size_t count)
 	return p;
 }
 
-__FORTIFY_INLINE void *memset(void *p, int c, __kernel_size_t size)
+__FORTIFY_INLINE void fortify_memset_chk(__kernel_size_t size,
+					 const size_t p_size,
+					 const size_t p_size_field)
 {
-	size_t p_size = __builtin_object_size(p, 0);
+	if (__builtin_constant_p(size)) {
+		/*
+		 * Length argument is a constant expression, so we
+		 * can perform compile-time bounds checking where
+		 * buffer sizes are known.
+		 */
 
-	if (__builtin_constant_p(size) && p_size < size)
-		__write_overflow();
-	if (p_size < size)
-		fortify_panic(__func__);
-	return __underlying_memset(p, c, size);
+		/* Error when size is larger than enclosing struct. */
+		if (p_size > p_size_field && p_size < size)
+			__write_overflow();
+
+		/* Warn when write size is larger than dest field. */
+		if (p_size_field < size)
+			__write_overflow_field(p_size_field, size);
+	}
+	/*
+	 * At this point, length argument may not be a constant expression,
+	 * so run-time bounds checking can be done where buffer sizes are
+	 * known. (This is not an "else" because the above checks may only
+	 * be compile-time warnings, and we want to still warn for run-time
+	 * overflows.)
+	 */
+
+	/*
+	 * Always stop accesses beyond the struct that contains the
+	 * field, when the buffer's remaining size is known.
+	 * (The -1 test is to optimize away checks where the buffer
+	 * lengths are unknown.)
+	 */
+	if (p_size != (size_t)(-1) && p_size < size)
+		fortify_panic("memset");
 }
 
+#define __fortify_memset_chk(p, c, size, p_size, p_size_field) ({	\
+	size_t __fortify_size = (size_t)(size);				\
+	fortify_memset_chk(__fortify_size, p_size, p_size_field),	\
+	__underlying_memset(p, c, __fortify_size);			\
+})
+
+/*
+ * __builtin_object_size() must be captured here to avoid evaluating argument
+ * side-effects further into the macro layers.
+ */
+#define memset(p, c, s) __fortify_memset_chk(p, c, s,			\
+		__builtin_object_size(p, 0), __builtin_object_size(p, 1))
+
 /*
  * To make sure the compiler can enforce protection against buffer overflows,
  * memcpy(), memmove(), and memset() must not be used beyond individual
@@ -401,7 +440,6 @@ __FORTIFY_INLINE char *strcpy(char *p, const char *q)
 /* Don't use these outside the FORITFY_SOURCE implementation */
 #undef __underlying_memchr
 #undef __underlying_memcmp
-#undef __underlying_memset
 #undef __underlying_strcat
 #undef __underlying_strcpy
 #undef __underlying_strlen
diff --git a/lib/test_fortify/write_overflow_field-memset.c b/lib/test_fortify/write_overflow_field-memset.c
new file mode 100644
index 000000000000..2331da26909e
--- /dev/null
+++ b/lib/test_fortify/write_overflow_field-memset.c
@@ -0,0 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#define TEST	\
+	memset(instance.buf, 0x42, sizeof(instance.buf) + 1)
+
+#include "test_fortify.h"
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* [PATCH 17/17] fortify: Work around Clang inlining bugs
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (15 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 16/17] fortify: Detect struct member overflows in memset() at compile-time Kees Cook
@ 2021-12-13 22:33 ` Kees Cook
  2021-12-14 13:22     ` kernel test robot
  2021-12-15  0:26 ` [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Jason Gunthorpe
  2021-12-17  4:04 ` Martin K. Petersen
  18 siblings, 1 reply; 43+ messages in thread
From: Kees Cook @ 2021-12-13 22:33 UTC (permalink / raw)
  To: linux-hardening; +Cc: Kees Cook, linux-kernel

To enable FORTIFY_SOURCE support for Clang, the kernel must work around
a pair of bugs, related to Clang's inlining.

Change all the fortified APIs into macros with different inline names to
bypass Clang's broken inline-of-a-builtin detection:
https://bugs.llvm.org/show_bug.cgi?id=50322

Lift all misbehaving __builtin_object_size() calls into the macros to
bypass Clang's broken __builtin_object_size() arguments-of-an-inline
visibility:
https://github.com/ClangBuiltLinux/linux/issues/1401

Thankfully, due to how the inlining already behaves in GCC, this change
has no effect on GCC builds, but allows Clang to finally gain full
FORTIFY coverage.

However, because of a third bug which had no work-arounds, FORTIFY_SOURCE
will only work with Clang version 13 and later. Update the Kconfig to
reflect the new requirements.

Clang 14 introduced compiletime_assert() support, so also adjust the
compile-time warning test to catch Clang's variant of the warning text.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/fortify-string.h | 65 +++++++++++++++++++++-------------
 scripts/test_fortify.sh        |  8 +++--
 security/Kconfig               |  2 +-
 3 files changed, 48 insertions(+), 27 deletions(-)

diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h
index c45159dbdaa1..04bcf8307f16 100644
--- a/include/linux/fortify-string.h
+++ b/include/linux/fortify-string.h
@@ -50,10 +50,10 @@ extern char *__underlying_strncpy(char *p, const char *q, __kernel_size_t size)
 #define __underlying_strncpy	__builtin_strncpy
 #endif
 
-__FORTIFY_INLINE char *strncpy(char *p, const char *q, __kernel_size_t size)
+#define strncpy(p, q, s) __fortify_strncpy(p, q, s, __builtin_object_size(p, 1))
+__FORTIFY_INLINE char *__fortify_strncpy(char *p, const char *q,
+					 __kernel_size_t size, size_t p_size)
 {
-	size_t p_size = __builtin_object_size(p, 1);
-
 	if (__builtin_constant_p(size) && p_size < size)
 		__write_overflow();
 	if (p_size < size)
@@ -73,9 +73,10 @@ __FORTIFY_INLINE char *strcat(char *p, const char *q)
 }
 
 extern __kernel_size_t __real_strnlen(const char *, __kernel_size_t) __RENAME(strnlen);
-__FORTIFY_INLINE __kernel_size_t strnlen(const char *p, __kernel_size_t maxlen)
+#define strnlen(p, s) __fortify_strnlen(p, s, __builtin_object_size(p, 1))
+__FORTIFY_INLINE __kernel_size_t __fortify_strnlen(const char *p, size_t maxlen,
+						   size_t p_size)
 {
-	size_t p_size = __builtin_object_size(p, 1);
 	size_t p_len = __compiletime_strlen(p);
 	size_t ret;
 
@@ -94,10 +95,10 @@ __FORTIFY_INLINE __kernel_size_t strnlen(const char *p, __kernel_size_t maxlen)
 }
 
 /* defined after fortified strnlen to reuse it. */
-__FORTIFY_INLINE __kernel_size_t strlen(const char *p)
+#define strlen(p) __fortify_strlen(p, __builtin_object_size(p, 1))
+__FORTIFY_INLINE __kernel_size_t __fortify_strlen(const char *p, const size_t p_size)
 {
 	__kernel_size_t ret;
-	size_t p_size = __builtin_object_size(p, 1);
 
 	/* Give up if we don't know how large p is. */
 	if (p_size == (size_t)-1)
@@ -110,10 +111,14 @@ __FORTIFY_INLINE __kernel_size_t strlen(const char *p)
 
 /* defined after fortified strlen to reuse it */
 extern size_t __real_strlcpy(char *, const char *, size_t) __RENAME(strlcpy);
-__FORTIFY_INLINE size_t strlcpy(char *p, const char *q, size_t size)
+#define strlcpy(p, q, s) __fortify_strlcpy(p, q, s,			\
+					   __builtin_object_size(p, 1),	\
+					   __builtin_object_size(q, 1))
+__FORTIFY_INLINE size_t __fortify_strlcpy(char *p, const char *q,
+					  size_t size,
+					  const size_t p_size,
+					  const size_t q_size)
 {
-	size_t p_size = __builtin_object_size(p, 1);
-	size_t q_size = __builtin_object_size(q, 1);
 	size_t q_len;	/* Full count of source string length. */
 	size_t len;	/* Count of characters going into destination. */
 
@@ -137,12 +142,15 @@ __FORTIFY_INLINE size_t strlcpy(char *p, const char *q, size_t size)
 
 /* defined after fortified strnlen to reuse it */
 extern ssize_t __real_strscpy(char *, const char *, size_t) __RENAME(strscpy);
-__FORTIFY_INLINE ssize_t strscpy(char *p, const char *q, size_t size)
+#define strscpy(p, q, s) __fortify_strscpy(p, q, s,			\
+					   __builtin_object_size(p, 1),	\
+					   __builtin_object_size(q, 1))
+__FORTIFY_INLINE ssize_t __fortify_strscpy(char *p, const char *q,
+					   size_t size,
+					   const size_t p_size,
+					   const size_t q_size)
 {
 	size_t len;
-	/* Use string size rather than possible enclosing struct size. */
-	size_t p_size = __builtin_object_size(p, 1);
-	size_t q_size = __builtin_object_size(q, 1);
 
 	/* If we cannot get size of p and q default to call strscpy. */
 	if (p_size == (size_t) -1 && q_size == (size_t) -1)
@@ -183,11 +191,13 @@ __FORTIFY_INLINE ssize_t strscpy(char *p, const char *q, size_t size)
 }
 
 /* defined after fortified strlen and strnlen to reuse them */
-__FORTIFY_INLINE char *strncat(char *p, const char *q, __kernel_size_t count)
+#define strncat(p, q, count)	__fortify_strncat(p, q, count, \
+						  __builtin_object_size(p, 1), \
+						  __builtin_object_size(q, 1))
+__FORTIFY_INLINE char *__fortify_strncat(char *p, const char *q, size_t count,
+					 size_t p_size, size_t q_size)
 {
 	size_t p_len, copy_len;
-	size_t p_size = __builtin_object_size(p, 1);
-	size_t q_size = __builtin_object_size(q, 1);
 
 	if (p_size == (size_t)-1 && q_size == (size_t)-1)
 		return __underlying_strncat(p, q, count);
@@ -354,7 +364,8 @@ __FORTIFY_INLINE void fortify_memcpy_chk(__kernel_size_t size,
 		memmove)
 
 extern void *__real_memscan(void *, int, __kernel_size_t) __RENAME(memscan);
-__FORTIFY_INLINE void *memscan(void *p, int c, __kernel_size_t size)
+#define memscan(p, c, s) __fortify_memscan(p, c, s)
+__FORTIFY_INLINE void *__fortify_memscan(void *p, int c, __kernel_size_t size)
 {
 	size_t p_size = __builtin_object_size(p, 0);
 
@@ -365,7 +376,8 @@ __FORTIFY_INLINE void *memscan(void *p, int c, __kernel_size_t size)
 	return __real_memscan(p, c, size);
 }
 
-__FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size)
+#define memcmp(p, q, s) __fortify_memcmp(p, q, s)
+__FORTIFY_INLINE int __fortify_memcmp(const void *p, const void *q, __kernel_size_t size)
 {
 	size_t p_size = __builtin_object_size(p, 0);
 	size_t q_size = __builtin_object_size(q, 0);
@@ -381,7 +393,8 @@ __FORTIFY_INLINE int memcmp(const void *p, const void *q, __kernel_size_t size)
 	return __underlying_memcmp(p, q, size);
 }
 
-__FORTIFY_INLINE void *memchr(const void *p, int c, __kernel_size_t size)
+#define memchr(p, c, s) __fortify_memchr(p, c, s)
+__FORTIFY_INLINE void *__fortify_memchr(const void *p, int c, __kernel_size_t size)
 {
 	size_t p_size = __builtin_object_size(p, 0);
 
@@ -393,7 +406,8 @@ __FORTIFY_INLINE void *memchr(const void *p, int c, __kernel_size_t size)
 }
 
 void *__real_memchr_inv(const void *s, int c, size_t n) __RENAME(memchr_inv);
-__FORTIFY_INLINE void *memchr_inv(const void *p, int c, size_t size)
+#define memchr_inv(p, c, s) __fortify_memchr_inv(p, c, s)
+__FORTIFY_INLINE void *__fortify_memchr_inv(const void *p, int c, size_t size)
 {
 	size_t p_size = __builtin_object_size(p, 0);
 
@@ -417,10 +431,13 @@ __FORTIFY_INLINE void *kmemdup(const void *p, size_t size, gfp_t gfp)
 }
 
 /* Defined after fortified strlen to reuse it. */
-__FORTIFY_INLINE char *strcpy(char *p, const char *q)
+#define strcpy(p, q) __fortify_strcpy(p, q,				\
+				      __builtin_object_size(p, 1),	\
+				      __builtin_object_size(q, 1))
+__FORTIFY_INLINE char *__fortify_strcpy(char *p, const char *q,
+					const size_t p_size,
+					const size_t q_size)
 {
-	size_t p_size = __builtin_object_size(p, 1);
-	size_t q_size = __builtin_object_size(q, 1);
 	size_t size;
 
 	/* If neither buffer size is known, immediately give up. */
diff --git a/scripts/test_fortify.sh b/scripts/test_fortify.sh
index a4da365508f0..c2688ab8281d 100644
--- a/scripts/test_fortify.sh
+++ b/scripts/test_fortify.sh
@@ -46,8 +46,12 @@ if "$@" -Werror -c "$IN" -o "$OUT".o 2> "$TMP" ; then
 		status="warning: unsafe ${FUNC}() usage lacked '$WANT' symbol in $IN"
 	fi
 else
-	# If the build failed, check for the warning in the stderr (gcc).
-	if ! grep -q -m1 "error: call to .\b${WANT}\b." "$TMP" ; then
+	# If the build failed, check for the warning in the stderr.
+	# GCC:
+	# ./include/linux/fortify-string.h:316:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
+	# Clang 14:
+	# ./include/linux/fortify-string.h:316:4: error: call to __write_overflow_field declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
+	if ! grep -Eq -m1 "error: call to .?\b${WANT}\b.?" "$TMP" ; then
 		status="warning: unsafe ${FUNC}() usage lacked '$WANT' warning in $IN"
 	fi
 fi
diff --git a/security/Kconfig b/security/Kconfig
index 0b847f435beb..1a25a567965f 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -179,7 +179,7 @@ config FORTIFY_SOURCE
 	depends on ARCH_HAS_FORTIFY_SOURCE
 	# https://bugs.llvm.org/show_bug.cgi?id=50322
 	# https://bugs.llvm.org/show_bug.cgi?id=41459
-	depends on !CC_IS_CLANG
+	depends on !CC_IS_CLANG || CLANG_VERSION >= 130000
 	help
 	  Detect overflows of buffers in common string and memory functions
 	  where the compiler can determine and validate the buffer sizes.
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
@ 2021-12-14  3:56   ` kernel test robot
  2021-12-14  8:46   ` kernel test robot
                     ` (5 subsequent siblings)
  6 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14  3:56 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 11370 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-s002-20211213 (https://download.01.org/0day-ci/archive/20211214/202112141126.S8eWMmlc-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout 80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/pci/endpoint/functions/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *[assigned] dst_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     expected void const *
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     got void [noderef] __iomem *[assigned] dst_addr
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *[assigned] src_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     expected void const *
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     got void [noderef] __iomem *[assigned] src_addr
>> drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *[assigned] dst_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     expected void const *
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     got void [noderef] __iomem *[assigned] dst_addr
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *[assigned] src_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     expected void const *
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     got void [noderef] __iomem *[assigned] src_addr
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void * @@     got void [noderef] __iomem *[assigned] dst_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     expected void *
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     got void [noderef] __iomem *[assigned] dst_addr
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *[assigned] src_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     expected void const *
   drivers/pci/endpoint/functions/pci-epf-test.c:288:17: sparse:     got void [noderef] __iomem *[assigned] src_addr

vim +288 drivers/pci/endpoint/functions/pci-epf-test.c

5893c2e5353bb9a Kishon Vijay Abraham I 2020-03-16  226  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  227  static int pci_epf_test_copy(struct pci_epf_test *epf_test)
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  228  {
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  229  	int ret;
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  230  	bool use_dma;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  231  	void __iomem *src_addr;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  232  	void __iomem *dst_addr;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  233  	phys_addr_t src_phys_addr;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  234  	phys_addr_t dst_phys_addr;
5893c2e5353bb9a Kishon Vijay Abraham I 2020-03-16  235  	struct timespec64 start, end;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  236  	struct pci_epf *epf = epf_test->epf;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  237  	struct device *dev = &epf->dev;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  238  	struct pci_epc *epc = epf->epc;
3235b994950d84d Kishon Vijay Abraham I 2017-08-18  239  	enum pci_barno test_reg_bar = epf_test->test_reg_bar;
3235b994950d84d Kishon Vijay Abraham I 2017-08-18  240  	struct pci_epf_test_reg *reg = epf_test->reg[test_reg_bar];
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  241  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  242  	src_addr = pci_epc_mem_alloc_addr(epc, &src_phys_addr, reg->size);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  243  	if (!src_addr) {
798c0441bec8c46 Gustavo Pimentel       2018-05-14  244  		dev_err(dev, "Failed to allocate source address\n");
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  245  		reg->status = STATUS_SRC_ADDR_INVALID;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  246  		ret = -ENOMEM;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  247  		goto err;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  248  	}
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  249  
53fd3cbe5e9d791 Kishon Vijay Abraham I 2021-08-19  250  	ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, src_phys_addr,
53fd3cbe5e9d791 Kishon Vijay Abraham I 2021-08-19  251  			       reg->src_addr, reg->size);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  252  	if (ret) {
798c0441bec8c46 Gustavo Pimentel       2018-05-14  253  		dev_err(dev, "Failed to map source address\n");
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  254  		reg->status = STATUS_SRC_ADDR_INVALID;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  255  		goto err_src_addr;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  256  	}
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  257  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  258  	dst_addr = pci_epc_mem_alloc_addr(epc, &dst_phys_addr, reg->size);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  259  	if (!dst_addr) {
798c0441bec8c46 Gustavo Pimentel       2018-05-14  260  		dev_err(dev, "Failed to allocate destination address\n");
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  261  		reg->status = STATUS_DST_ADDR_INVALID;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  262  		ret = -ENOMEM;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  263  		goto err_src_map_addr;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  264  	}
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  265  
53fd3cbe5e9d791 Kishon Vijay Abraham I 2021-08-19  266  	ret = pci_epc_map_addr(epc, epf->func_no, epf->vfunc_no, dst_phys_addr,
53fd3cbe5e9d791 Kishon Vijay Abraham I 2021-08-19  267  			       reg->dst_addr, reg->size);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  268  	if (ret) {
798c0441bec8c46 Gustavo Pimentel       2018-05-14  269  		dev_err(dev, "Failed to map destination address\n");
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  270  		reg->status = STATUS_DST_ADDR_INVALID;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  271  		goto err_dst_addr;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  272  	}
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  273  
5893c2e5353bb9a Kishon Vijay Abraham I 2020-03-16  274  	ktime_get_ts64(&start);
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  275  	use_dma = !!(reg->flags & FLAG_USE_DMA);
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  276  	if (use_dma) {
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  277  		if (!epf_test->dma_supported) {
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  278  			dev_err(dev, "Cannot transfer data using DMA\n");
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  279  			ret = -EINVAL;
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  280  			goto err_map_addr;
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  281  		}
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  282  
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  283  		ret = pci_epf_test_data_transfer(epf_test, dst_phys_addr,
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  284  						 src_phys_addr, reg->size);
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  285  		if (ret)
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  286  			dev_err(dev, "Data transfer failed\n");
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  287  	} else {
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27 @288  		memcpy(dst_addr, src_addr, reg->size);
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  289  	}
5893c2e5353bb9a Kishon Vijay Abraham I 2020-03-16  290  	ktime_get_ts64(&end);
5893c2e5353bb9a Kishon Vijay Abraham I 2020-03-16  291  	pci_epf_test_print_rate("COPY", reg->size, &start, &end, use_dma);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  292  
5ebf3fc59bd20d1 Kishon Vijay Abraham I 2020-03-16  293  err_map_addr:
53fd3cbe5e9d791 Kishon Vijay Abraham I 2021-08-19  294  	pci_epc_unmap_addr(epc, epf->func_no, epf->vfunc_no, dst_phys_addr);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  295  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  296  err_dst_addr:
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  297  	pci_epc_mem_free_addr(epc, dst_phys_addr, dst_addr, reg->size);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  298  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  299  err_src_map_addr:
53fd3cbe5e9d791 Kishon Vijay Abraham I 2021-08-19  300  	pci_epc_unmap_addr(epc, epf->func_no, epf->vfunc_no, src_phys_addr);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  301  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  302  err_src_addr:
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  303  	pci_epc_mem_free_addr(epc, src_phys_addr, src_addr, reg->size);
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  304  
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  305  err:
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  306  	return ret;
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  307  }
349e7a85b25fa6e Kishon Vijay Abraham I 2017-03-27  308  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
  2021-12-13 22:33   ` Kees Cook
@ 2021-12-14  6:02     ` Kalle Valo
  -1 siblings, 0 replies; 43+ messages in thread
From: Kalle Valo @ 2021-12-14  6:02 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

Kees Cook <keescook@chromium.org> writes:

> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Use memset_startat() so memset() doesn't get confused about writing
> beyond the destination member that is intended to be the starting point
> of zeroing through the end of the struct. Additionally split up a later
> field-spanning memset() so that memset() can reason about the size.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: ath11k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>

What's the plan for this patch? I would like to take this via my ath
tree to avoid conflicts.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
@ 2021-12-14  6:02     ` Kalle Valo
  0 siblings, 0 replies; 43+ messages in thread
From: Kalle Valo @ 2021-12-14  6:02 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

Kees Cook <keescook@chromium.org> writes:

> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Use memset_startat() so memset() doesn't get confused about writing
> beyond the destination member that is intended to be the starting point
> of zeroing through the end of the struct. Additionally split up a later
> field-spanning memset() so that memset() can reason about the size.
>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: ath11k@lists.infradead.org
> Cc: linux-wireless@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>

What's the plan for this patch? I would like to take this via my ath
tree to avoid conflicts.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
  2021-12-14  3:56   ` kernel test robot
@ 2021-12-14  8:46   ` kernel test robot
  2021-12-14 11:50   ` kernel test robot
                     ` (4 subsequent siblings)
  6 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14  8:46 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 7981 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: x86_64-randconfig-s022-20211213 (https://download.01.org/0day-ci/archive/20211214/202112141639.6sg1Fhdq-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout 80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/acpi/apei/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/acpi/apei/erst.c:272:13: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected void *src @@     got void [noderef] __iomem * @@
   drivers/acpi/apei/erst.c:272:13: sparse:     expected void *src
   drivers/acpi/apei/erst.c:272:13: sparse:     got void [noderef] __iomem *
   drivers/acpi/apei/erst.c:275:13: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected void *dst @@     got void [noderef] __iomem * @@
   drivers/acpi/apei/erst.c:275:13: sparse:     expected void *dst
   drivers/acpi/apei/erst.c:275:13: sparse:     got void [noderef] __iomem *
   drivers/acpi/apei/erst.c:277:25: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *addr @@     got void *src @@
   drivers/acpi/apei/erst.c:277:25: sparse:     expected void volatile [noderef] __iomem *addr
   drivers/acpi/apei/erst.c:277:25: sparse:     got void *src
   drivers/acpi/apei/erst.c:283:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *addr @@     got void *src @@
   drivers/acpi/apei/erst.c:283:17: sparse:     expected void volatile [noderef] __iomem *addr
   drivers/acpi/apei/erst.c:283:17: sparse:     got void *src
   drivers/acpi/apei/erst.c:284:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void volatile [noderef] __iomem *addr @@     got void *dst @@
   drivers/acpi/apei/erst.c:284:17: sparse:     expected void volatile [noderef] __iomem *addr
   drivers/acpi/apei/erst.c:284:17: sparse:     got void *dst
>> drivers/acpi/apei/erst.c:792:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *static [toplevel] vaddr @@
   drivers/acpi/apei/erst.c:792:9: sparse:     expected void const *
   drivers/acpi/apei/erst.c:792:9: sparse:     got void [noderef] __iomem *static [toplevel] vaddr
>> drivers/acpi/apei/erst.c:792:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *static [toplevel] vaddr @@
   drivers/acpi/apei/erst.c:792:9: sparse:     expected void const *
   drivers/acpi/apei/erst.c:792:9: sparse:     got void [noderef] __iomem *static [toplevel] vaddr
   drivers/acpi/apei/erst.c:792:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void * @@     got void [noderef] __iomem *static [toplevel] vaddr @@
   drivers/acpi/apei/erst.c:792:9: sparse:     expected void *
   drivers/acpi/apei/erst.c:792:9: sparse:     got void [noderef] __iomem *static [toplevel] vaddr
   drivers/acpi/apei/erst.c:793:20: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected struct cper_record_header *rcd_erange @@     got void [noderef] __iomem *static [toplevel] vaddr @@
   drivers/acpi/apei/erst.c:793:20: sparse:     expected struct cper_record_header *rcd_erange
   drivers/acpi/apei/erst.c:793:20: sparse:     got void [noderef] __iomem *static [toplevel] vaddr
   drivers/acpi/apei/erst.c:830:17: sparse: sparse: incorrect type in assignment (different address spaces) @@     expected struct cper_record_header *rcd_tmp @@     got void [noderef] __iomem * @@
   drivers/acpi/apei/erst.c:830:17: sparse:     expected struct cper_record_header *rcd_tmp
   drivers/acpi/apei/erst.c:830:17: sparse:     got void [noderef] __iomem *

vim +792 drivers/acpi/apei/erst.c

a08f82d08053fb Huang Ying 2010-05-18  766  
a08f82d08053fb Huang Ying 2010-05-18  767  int erst_write(const struct cper_record_header *record)
a08f82d08053fb Huang Ying 2010-05-18  768  {
a08f82d08053fb Huang Ying 2010-05-18  769  	int rc;
a08f82d08053fb Huang Ying 2010-05-18  770  	unsigned long flags;
a08f82d08053fb Huang Ying 2010-05-18  771  	struct cper_record_header *rcd_erange;
a08f82d08053fb Huang Ying 2010-05-18  772  
a08f82d08053fb Huang Ying 2010-05-18  773  	if (erst_disable)
a08f82d08053fb Huang Ying 2010-05-18  774  		return -ENODEV;
a08f82d08053fb Huang Ying 2010-05-18  775  
a08f82d08053fb Huang Ying 2010-05-18  776  	if (memcmp(record->signature, CPER_SIG_RECORD, CPER_SIG_SIZE))
a08f82d08053fb Huang Ying 2010-05-18  777  		return -EINVAL;
a08f82d08053fb Huang Ying 2010-05-18  778  
a08f82d08053fb Huang Ying 2010-05-18  779  	if (erst_erange.attr & ERST_RANGE_NVRAM) {
3b38bb5f7f0635 Huang Ying 2010-12-02  780  		if (!raw_spin_trylock_irqsave(&erst_lock, flags))
a08f82d08053fb Huang Ying 2010-05-18  781  			return -EBUSY;
a08f82d08053fb Huang Ying 2010-05-18  782  		rc = __erst_write_to_nvram(record);
3b38bb5f7f0635 Huang Ying 2010-12-02  783  		raw_spin_unlock_irqrestore(&erst_lock, flags);
a08f82d08053fb Huang Ying 2010-05-18  784  		return rc;
a08f82d08053fb Huang Ying 2010-05-18  785  	}
a08f82d08053fb Huang Ying 2010-05-18  786  
a08f82d08053fb Huang Ying 2010-05-18  787  	if (record->record_length > erst_erange.size)
a08f82d08053fb Huang Ying 2010-05-18  788  		return -EINVAL;
a08f82d08053fb Huang Ying 2010-05-18  789  
3b38bb5f7f0635 Huang Ying 2010-12-02  790  	if (!raw_spin_trylock_irqsave(&erst_lock, flags))
a08f82d08053fb Huang Ying 2010-05-18  791  		return -EBUSY;
a08f82d08053fb Huang Ying 2010-05-18 @792  	memcpy(erst_erange.vaddr, record, record->record_length);
a08f82d08053fb Huang Ying 2010-05-18  793  	rcd_erange = erst_erange.vaddr;
a08f82d08053fb Huang Ying 2010-05-18  794  	/* signature for serialization system */
a08f82d08053fb Huang Ying 2010-05-18  795  	memcpy(&rcd_erange->persistence_information, "ER", 2);
a08f82d08053fb Huang Ying 2010-05-18  796  
a08f82d08053fb Huang Ying 2010-05-18  797  	rc = __erst_write_to_storage(0);
3b38bb5f7f0635 Huang Ying 2010-12-02  798  	raw_spin_unlock_irqrestore(&erst_lock, flags);
a08f82d08053fb Huang Ying 2010-05-18  799  
a08f82d08053fb Huang Ying 2010-05-18  800  	return rc;
a08f82d08053fb Huang Ying 2010-05-18  801  }
a08f82d08053fb Huang Ying 2010-05-18  802  EXPORT_SYMBOL_GPL(erst_write);
a08f82d08053fb Huang Ying 2010-05-18  803  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
  2021-12-14  3:56   ` kernel test robot
  2021-12-14  8:46   ` kernel test robot
@ 2021-12-14 11:50   ` kernel test robot
  2021-12-14 16:32   ` kernel test robot
                     ` (3 subsequent siblings)
  6 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14 11:50 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 11202 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: riscv-randconfig-s031-20211214 (https://download.01.org/0day-ci/archive/20211214/202112141904.hqRtWx0l-lkp(a)intel.com/config)
compiler: riscv32-linux-gcc (GCC) 11.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout 80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=riscv SHELL=/bin/bash drivers/video/fbdev/core/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
   drivers/video/fbdev/core/fbmem.c:808:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got unsigned char [noderef] [usertype] __iomem *[assigned] src @@
   drivers/video/fbdev/core/fbmem.c:808:17: sparse:     expected void const *
   drivers/video/fbdev/core/fbmem.c:808:17: sparse:     got unsigned char [noderef] [usertype] __iomem *[assigned] src
   drivers/video/fbdev/core/fbmem.c:808:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got unsigned char [noderef] [usertype] __iomem *[assigned] src @@
   drivers/video/fbdev/core/fbmem.c:808:17: sparse:     expected void const *
   drivers/video/fbdev/core/fbmem.c:808:17: sparse:     got unsigned char [noderef] [usertype] __iomem *[assigned] src
   drivers/video/fbdev/core/fbmem.c:808:17: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got unsigned char [noderef] [usertype] __iomem *[assigned] src @@
   drivers/video/fbdev/core/fbmem.c:808:17: sparse:     expected void const *
   drivers/video/fbdev/core/fbmem.c:808:17: sparse:     got unsigned char [noderef] [usertype] __iomem *[assigned] src
>> drivers/video/fbdev/core/fbmem.c:885:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got unsigned char [noderef] [usertype] __iomem *[assigned] dst @@
   drivers/video/fbdev/core/fbmem.c:885:17: sparse:     expected void const *
   drivers/video/fbdev/core/fbmem.c:885:17: sparse:     got unsigned char [noderef] [usertype] __iomem *[assigned] dst
>> drivers/video/fbdev/core/fbmem.c:885:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got unsigned char [noderef] [usertype] __iomem *[assigned] dst @@
   drivers/video/fbdev/core/fbmem.c:885:17: sparse:     expected void const *
   drivers/video/fbdev/core/fbmem.c:885:17: sparse:     got unsigned char [noderef] [usertype] __iomem *[assigned] dst
   drivers/video/fbdev/core/fbmem.c:885:17: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void * @@     got unsigned char [noderef] [usertype] __iomem *[assigned] dst @@
   drivers/video/fbdev/core/fbmem.c:885:17: sparse:     expected void *
   drivers/video/fbdev/core/fbmem.c:885:17: sparse:     got unsigned char [noderef] [usertype] __iomem *[assigned] dst

vim +885 drivers/video/fbdev/core/fbmem.c

^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  826  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  827  static ssize_t
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  828  fb_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos)
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  829  {
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  830  	unsigned long p = *ppos;
c47747fde931c0 drivers/video/fbmem.c Linus Torvalds     2011-05-11  831  	struct fb_info *info = file_fb_info(file);
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27  832  	u8 *buffer, *src;
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27  833  	u8 __iomem *dst;
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27  834  	int c, cnt = 0, err = 0;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  835  	unsigned long total_size;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  836  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  837  	if (!info || !info->screen_base)
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  838  		return -ENODEV;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  839  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  840  	if (info->state != FBINFO_STATE_RUNNING)
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  841  		return -EPERM;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  842  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  843  	if (info->fbops->fb_write)
3f9b0880e4a96b drivers/video/fbmem.c Antonino A. Daplas 2007-05-08  844  		return info->fbops->fb_write(info, buf, count, ppos);
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  845  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  846  	total_size = info->screen_size;
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  847  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  848  	if (total_size == 0)
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  849  		total_size = info->fix.smem_len;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  850  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  851  	if (p > total_size)
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  852  		return -EFBIG;
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  853  
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  854  	if (count > total_size) {
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  855  		err = -EFBIG;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  856  		count = total_size;
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  857  	}
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  858  
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  859  	if (count + p > total_size) {
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  860  		if (!err)
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  861  			err = -ENOSPC;
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  862  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  863  		count = total_size - p;
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  864  	}
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  865  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  866  	buffer = kmalloc((count > PAGE_SIZE) ? PAGE_SIZE : count,
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  867  			 GFP_KERNEL);
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  868  	if (!buffer)
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  869  		return -ENOMEM;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  870  
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27  871  	dst = (u8 __iomem *) (info->screen_base + p);
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  872  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  873  	if (info->fbops->fb_sync)
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  874  		info->fbops->fb_sync(info);
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  875  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  876  	while (count) {
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  877  		c = (count > PAGE_SIZE) ? PAGE_SIZE : count;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  878  		src = buffer;
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  879  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  880  		if (copy_from_user(src, buf, c)) {
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  881  			err = -EFAULT;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  882  			break;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  883  		}
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  884  
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27 @885  		fb_memcpy_tofb(dst, src, c);
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27  886  		dst += c;
f11b478d461b71 drivers/video/fbmem.c James Hogan        2010-10-27  887  		src += c;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  888  		*ppos += c;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  889  		buf += c;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  890  		cnt += c;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  891  		count -= c;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  892  	}
0a484a3af905a2 drivers/video/fbmem.c Antonino A. Daplas 2006-01-09  893  
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  894  	kfree(buffer);
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  895  
6a2a88668e90cd drivers/video/fbmem.c Antonino A. Daplas 2006-04-18  896  	return (cnt) ? cnt : err;
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  897  }
^1da177e4c3f41 drivers/video/fbmem.c Linus Torvalds     2005-04-16  898  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 16/17] fortify: Detect struct member overflows in memset() at compile-time
  2021-12-13 22:33 ` [PATCH 16/17] fortify: Detect struct member overflows in memset() at compile-time Kees Cook
@ 2021-12-14 12:31   ` kernel test robot
  0 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14 12:31 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 15624 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-s001-20211214 (https://download.01.org/0day-ci/archive/20211214/202112142014.LCVuJteC-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/5827537ce9a9fe9059d982a74a6cd7afeccc9145
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout 5827537ce9a9fe9059d982a74a6cd7afeccc9145
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/video/fbdev/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/i740fb.c:743:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got char [noderef] __iomem *screen_base @@
   drivers/video/fbdev/i740fb.c:743:9: sparse:     expected void const *
   drivers/video/fbdev/i740fb.c:743:9: sparse:     got char [noderef] __iomem *screen_base
>> drivers/video/fbdev/i740fb.c:743:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got char [noderef] __iomem *screen_base @@
   drivers/video/fbdev/i740fb.c:743:9: sparse:     expected void const *
   drivers/video/fbdev/i740fb.c:743:9: sparse:     got char [noderef] __iomem *screen_base
   drivers/video/fbdev/i740fb.c:743:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void * @@     got char [noderef] __iomem *screen_base @@
   drivers/video/fbdev/i740fb.c:743:9: sparse:     expected void *
   drivers/video/fbdev/i740fb.c:743:9: sparse:     got char [noderef] __iomem *screen_base

vim +743 drivers/video/fbdev/i740fb.c

5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  732  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  733  static int i740fb_set_par(struct fb_info *info)
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  734  {
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  735  	struct i740fb_par *par = info->par;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  736  	u32 itemp;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  737  	int i;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  738  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  739  	i = i740fb_decode_var(&info->var, par, info);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  740  	if (i)
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  741  		return i;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  742  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10 @743  	memset(info->screen_base, 0, info->screen_size);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  744  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  745  	vga_protect(par);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  746  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  747  	i740outreg(par, XRX, DRAM_EXT_CNTL, DRAM_REFRESH_DISABLE);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  748  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  749  	mdelay(1);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  750  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  751  	i740outreg(par, XRX, VCLK2_VCO_M, par->video_clk2_m);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  752  	i740outreg(par, XRX, VCLK2_VCO_N, par->video_clk2_n);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  753  	i740outreg(par, XRX, VCLK2_VCO_MN_MSBS, par->video_clk2_mn_msbs);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  754  	i740outreg(par, XRX, VCLK2_VCO_DIV_SEL, par->video_clk2_div_sel);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  755  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  756  	i740outreg_mask(par, XRX, PIXPIPE_CONFIG_0,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  757  			par->pixelpipe_cfg0 & DAC_8_BIT, 0x80);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  758  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  759  	i740inb(par, 0x3DA);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  760  	i740outb(par, 0x3C0, 0x00);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  761  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  762  	/* update misc output register */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  763  	i740outb(par, VGA_MIS_W, par->misc | 0x01);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  764  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  765  	/* synchronous reset on */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  766  	i740outreg(par, VGA_SEQ_I, VGA_SEQ_RESET, 0x01);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  767  	/* write sequencer registers */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  768  	i740outreg(par, VGA_SEQ_I, VGA_SEQ_CLOCK_MODE,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  769  			par->seq[VGA_SEQ_CLOCK_MODE] | 0x20);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  770  	for (i = 2; i < VGA_SEQ_C; i++)
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  771  		i740outreg(par, VGA_SEQ_I, i, par->seq[i]);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  772  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  773  	/* synchronous reset off */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  774  	i740outreg(par, VGA_SEQ_I, VGA_SEQ_RESET, 0x03);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  775  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  776  	/* deprotect CRT registers 0-7 */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  777  	i740outreg(par, VGA_CRT_IC, VGA_CRTC_V_SYNC_END,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  778  			par->crtc[VGA_CRTC_V_SYNC_END]);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  779  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  780  	/* write CRT registers */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  781  	for (i = 0; i < VGA_CRT_C; i++)
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  782  		i740outreg(par, VGA_CRT_IC, i, par->crtc[i]);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  783  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  784  	/* write graphics controller registers */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  785  	for (i = 0; i < VGA_GFX_C; i++)
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  786  		i740outreg(par, VGA_GFX_I, i, par->gdc[i]);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  787  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  788  	/* write attribute controller registers */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  789  	for (i = 0; i < VGA_ATT_C; i++) {
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  790  		i740inb(par, VGA_IS1_RC);		/* reset flip-flop */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  791  		i740outb(par, VGA_ATT_IW, i);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  792  		i740outb(par, VGA_ATT_IW, par->atc[i]);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  793  	}
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  794  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  795  	i740inb(par, VGA_IS1_RC);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  796  	i740outb(par, VGA_ATT_IW, 0x20);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  797  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  798  	i740outreg(par, VGA_CRT_IC, EXT_VERT_TOTAL, par->ext_vert_total);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  799  	i740outreg(par, VGA_CRT_IC, EXT_VERT_DISPLAY, par->ext_vert_disp_end);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  800  	i740outreg(par, VGA_CRT_IC, EXT_VERT_SYNC_START,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  801  			par->ext_vert_sync_start);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  802  	i740outreg(par, VGA_CRT_IC, EXT_VERT_BLANK_START,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  803  			par->ext_vert_blank_start);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  804  	i740outreg(par, VGA_CRT_IC, EXT_HORIZ_TOTAL, par->ext_horiz_total);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  805  	i740outreg(par, VGA_CRT_IC, EXT_HORIZ_BLANK, par->ext_horiz_blank);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  806  	i740outreg(par, VGA_CRT_IC, EXT_OFFSET, par->ext_offset);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  807  	i740outreg(par, VGA_CRT_IC, EXT_START_ADDR_HI, par->ext_start_addr_hi);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  808  	i740outreg(par, VGA_CRT_IC, EXT_START_ADDR, par->ext_start_addr);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  809  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  810  	i740outreg_mask(par, VGA_CRT_IC, INTERLACE_CNTL,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  811  			par->interlace_cntl, INTERLACE_ENABLE);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  812  	i740outreg_mask(par, XRX, ADDRESS_MAPPING, par->address_mapping, 0x1F);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  813  	i740outreg_mask(par, XRX, BITBLT_CNTL, par->bitblt_cntl, COLEXP_MODE);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  814  	i740outreg_mask(par, XRX, DISPLAY_CNTL,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  815  			par->display_cntl, VGA_WRAP_MODE | GUI_MODE);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  816  	i740outreg_mask(par, XRX, PIXPIPE_CONFIG_0, par->pixelpipe_cfg0, 0x9B);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  817  	i740outreg_mask(par, XRX, PIXPIPE_CONFIG_2, par->pixelpipe_cfg2, 0x0C);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  818  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  819  	i740outreg(par, XRX, PLL_CNTL, par->pll_cntl);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  820  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  821  	i740outreg_mask(par, XRX, PIXPIPE_CONFIG_1,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  822  			par->pixelpipe_cfg1, DISPLAY_COLOR_MODE);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  823  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  824  	itemp = readl(par->regs + FWATER_BLC);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  825  	itemp &= ~(LMI_BURST_LENGTH | LMI_FIFO_WATERMARK);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  826  	itemp |= par->lmi_fifo_watermark;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  827  	writel(itemp, par->regs + FWATER_BLC);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  828  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  829  	i740outreg(par, XRX, DRAM_EXT_CNTL, DRAM_REFRESH_60HZ);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  830  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  831  	i740outreg_mask(par, MRX, COL_KEY_CNTL_1, 0, BLANK_DISP_OVERLAY);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  832  	i740outreg_mask(par, XRX, IO_CTNL,
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  833  			par->io_cntl, EXTENDED_ATTR_CNTL | EXTENDED_CRTC_CNTL);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  834  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  835  	if (par->pixelpipe_cfg1 != DISPLAY_8BPP_MODE) {
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  836  		i740outb(par, VGA_PEL_MSK, 0xFF);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  837  		i740outb(par, VGA_PEL_IW, 0x00);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  838  		for (i = 0; i < 256; i++) {
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  839  			itemp = (par->pixelpipe_cfg0 & DAC_8_BIT) ? i : i >> 2;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  840  			i740outb(par, VGA_PEL_D, itemp);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  841  			i740outb(par, VGA_PEL_D, itemp);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  842  			i740outb(par, VGA_PEL_D, itemp);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  843  		}
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  844  	}
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  845  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  846  	/* Wait for screen to stabilize. */
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  847  	mdelay(50);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  848  	vga_unprotect(par);
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  849  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  850  	info->fix.line_length =
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  851  			info->var.xres_virtual * info->var.bits_per_pixel / 8;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  852  	if (info->var.bits_per_pixel == 8)
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  853  		info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  854  	else
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  855  		info->fix.visual = FB_VISUAL_TRUECOLOR;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  856  
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  857  	return 0;
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  858  }
5350c65f4f15bb drivers/video/i740fb.c Ondrej Zary 2012-02-10  859  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 17/17] fortify: Work around Clang inlining bugs
  2021-12-13 22:33 ` [PATCH 17/17] fortify: Work around Clang inlining bugs Kees Cook
@ 2021-12-14 13:22     ` kernel test robot
  0 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14 13:22 UTC (permalink / raw)
  To: Kees Cook; +Cc: llvm, kbuild-all

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-r003-20211213 (https://download.01.org/0day-ci/archive/20211214/202112142158.n5ChiotI-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project b6a2ddb6c8ac29412b1361810972e15221fa021c)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/e5d600e1abbdd2034dbc844654957a4ec1182dbf
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout e5d600e1abbdd2034dbc844654957a4ec1182dbf
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> warning: unsafe strlcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strlcpy.c
--
>> warning: unsafe strlcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strlcpy-src.c
--
>> warning: unsafe strcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strcpy-lit.c
--
>> warning: unsafe strcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strcpy.c

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 17/17] fortify: Work around Clang inlining bugs
@ 2021-12-14 13:22     ` kernel test robot
  0 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14 13:22 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-r003-20211213 (https://download.01.org/0day-ci/archive/20211214/202112142158.n5ChiotI-lkp(a)intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project b6a2ddb6c8ac29412b1361810972e15221fa021c)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/e5d600e1abbdd2034dbc844654957a4ec1182dbf
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout e5d600e1abbdd2034dbc844654957a4ec1182dbf
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> warning: unsafe strlcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strlcpy.c
--
>> warning: unsafe strlcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strlcpy-src.c
--
>> warning: unsafe strcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strcpy-lit.c
--
>> warning: unsafe strcpy() usage lacked '__write_overflow' symbol in lib/test_fortify/write_overflow-strcpy.c

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
  2021-12-14  6:02     ` Kalle Valo
@ 2021-12-14 15:46       ` Kalle Valo
  -1 siblings, 0 replies; 43+ messages in thread
From: Kalle Valo @ 2021-12-14 15:46 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

Kalle Valo <kvalo@kernel.org> writes:

> Kees Cook <keescook@chromium.org> writes:
>
>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> field bounds checking for memset(), avoid intentionally writing across
>> neighboring fields.
>>
>> Use memset_startat() so memset() doesn't get confused about writing
>> beyond the destination member that is intended to be the starting point
>> of zeroing through the end of the struct. Additionally split up a later
>> field-spanning memset() so that memset() can reason about the size.
>>
>> Cc: Kalle Valo <kvalo@codeaurora.org>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Jakub Kicinski <kuba@kernel.org>
>> Cc: ath11k@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> What's the plan for this patch? I would like to take this via my ath
> tree to avoid conflicts.

Actually this has been already applied:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=d5549e9a6b86

Why are you submitting the same patch twice?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
@ 2021-12-14 15:46       ` Kalle Valo
  0 siblings, 0 replies; 43+ messages in thread
From: Kalle Valo @ 2021-12-14 15:46 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

Kalle Valo <kvalo@kernel.org> writes:

> Kees Cook <keescook@chromium.org> writes:
>
>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> field bounds checking for memset(), avoid intentionally writing across
>> neighboring fields.
>>
>> Use memset_startat() so memset() doesn't get confused about writing
>> beyond the destination member that is intended to be the starting point
>> of zeroing through the end of the struct. Additionally split up a later
>> field-spanning memset() so that memset() can reason about the size.
>>
>> Cc: Kalle Valo <kvalo@codeaurora.org>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Jakub Kicinski <kuba@kernel.org>
>> Cc: ath11k@lists.infradead.org
>> Cc: linux-wireless@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>
> What's the plan for this patch? I would like to take this via my ath
> tree to avoid conflicts.

Actually this has been already applied:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=d5549e9a6b86

Why are you submitting the same patch twice?

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
                     ` (2 preceding siblings ...)
  2021-12-14 11:50   ` kernel test robot
@ 2021-12-14 16:32   ` kernel test robot
  2021-12-14 19:06   ` kernel test robot
                     ` (2 subsequent siblings)
  6 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14 16:32 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 29532 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5 next-20211213]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-s002-20211214 (https://download.01.org/0day-ci/archive/20211215/202112150059.yHZrJY0I-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout 80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/video/fbdev/geode/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *gp_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse:     got void [noderef] __iomem *gp_regs
>> drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *gp_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse:     got void [noderef] __iomem *gp_regs
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *gp_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:602:9: sparse:     got void [noderef] __iomem *gp_regs
>> drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *dc_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse:     got void [noderef] __iomem *dc_regs
>> drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *dc_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse:     got void [noderef] __iomem *dc_regs
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *dc_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:603:9: sparse:     got void [noderef] __iomem *dc_regs
>> drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *vp_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse:     got void [noderef] __iomem *vp_regs
>> drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *vp_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse:     got void [noderef] __iomem *vp_regs
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *vp_regs @@
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:604:9: sparse:     got void [noderef] __iomem *vp_regs
>> drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse:     got void [noderef] __iomem *
>> drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:605:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:633:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse:     expected void const *
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse:     got void [noderef] __iomem *
>> drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse:     expected void *
   drivers/video/fbdev/geode/lxfb_ops.c:760:9: sparse:     got void [noderef] __iomem *

vim +602 drivers/video/fbdev/geode/lxfb_ops.c

f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  582  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  583  static void lx_save_regs(struct lxfb_par *par)
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  584  {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  585  	uint32_t filt;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  586  	int i;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  587  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  588  	/* wait for the BLT engine to stop being busy */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  589  	do {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  590  		i = read_gp(par, GP_BLT_STATUS);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  591  	} while ((i & GP_BLT_STATUS_PB) || !(i & GP_BLT_STATUS_CE));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  592  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  593  	/* save MSRs */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  594  	rdmsrl(MSR_LX_MSR_PADSEL, par->msr.padsel);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  595  	rdmsrl(MSR_GLCP_DOTPLL, par->msr.dotpll);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  596  	rdmsrl(MSR_LX_GLD_MSR_CONFIG, par->msr.dfglcfg);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  597  	rdmsrl(MSR_LX_SPARE_MSR, par->msr.dcspare);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  598  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  599  	write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  600  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  601  	/* save registers */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28 @602  	memcpy(par->gp, par->gp_regs, sizeof(par->gp));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28 @603  	memcpy(par->dc, par->dc_regs, sizeof(par->dc));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28 @604  	memcpy(par->vp, par->vp_regs, sizeof(par->vp));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28 @605  	memcpy(par->fp, par->vp_regs + VP_FP_START, sizeof(par->fp));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  606  
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  607  	/* save the display controller palette */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  608  	write_dc(par, DC_PAL_ADDRESS, 0);
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  609  	for (i = 0; i < ARRAY_SIZE(par->dc_pal); i++)
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  610  		par->dc_pal[i] = read_dc(par, DC_PAL_DATA);
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  611  
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  612  	/* save the video processor palette */
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  613  	write_vp(par, VP_PAR, 0);
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  614  	for (i = 0; i < ARRAY_SIZE(par->vp_pal); i++)
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  615  		par->vp_pal[i] = read_vp(par, VP_PDR);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  616  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  617  	/* save the horizontal filter coefficients */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  618  	filt = par->dc[DC_IRQ_FILT_CTL] | DC_IRQ_FILT_CTL_H_FILT_SEL;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  619  	for (i = 0; i < ARRAY_SIZE(par->hcoeff); i += 2) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  620  		write_dc(par, DC_IRQ_FILT_CTL, (filt & 0xffffff00) | i);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  621  		par->hcoeff[i] = read_dc(par, DC_FILT_COEFF1);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  622  		par->hcoeff[i + 1] = read_dc(par, DC_FILT_COEFF2);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  623  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  624  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  625  	/* save the vertical filter coefficients */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  626  	filt &= ~DC_IRQ_FILT_CTL_H_FILT_SEL;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  627  	for (i = 0; i < ARRAY_SIZE(par->vcoeff); i++) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  628  		write_dc(par, DC_IRQ_FILT_CTL, (filt & 0xffffff00) | i);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  629  		par->vcoeff[i] = read_dc(par, DC_FILT_COEFF1);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  630  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  631  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  632  	/* save video coeff ram */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  633  	memcpy(par->vp_coeff, par->vp_regs + VP_VCR, sizeof(par->vp_coeff));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  634  }
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  635  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  636  static void lx_restore_gfx_proc(struct lxfb_par *par)
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  637  {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  638  	int i;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  639  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  640  	/* a bunch of registers require GP_RASTER_MODE to be set first */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  641  	write_gp(par, GP_RASTER_MODE, par->gp[GP_RASTER_MODE]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  642  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  643  	for (i = 0; i < ARRAY_SIZE(par->gp); i++) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  644  		switch (i) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  645  		case GP_RASTER_MODE:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  646  		case GP_VECTOR_MODE:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  647  		case GP_BLT_MODE:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  648  		case GP_BLT_STATUS:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  649  		case GP_HST_SRC:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  650  			/* FIXME: restore LUT data */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  651  		case GP_LUT_INDEX:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  652  		case GP_LUT_DATA:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  653  			/* don't restore these registers */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  654  			break;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  655  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  656  		default:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  657  			write_gp(par, i, par->gp[i]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  658  		}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  659  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  660  }
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  661  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  662  static void lx_restore_display_ctlr(struct lxfb_par *par)
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  663  {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  664  	uint32_t filt;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  665  	int i;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  666  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  667  	wrmsrl(MSR_LX_SPARE_MSR, par->msr.dcspare);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  668  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  669  	for (i = 0; i < ARRAY_SIZE(par->dc); i++) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  670  		switch (i) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  671  		case DC_UNLOCK:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  672  			/* unlock the DC; runs first */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  673  			write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  674  			break;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  675  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  676  		case DC_GENERAL_CFG:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  677  		case DC_DISPLAY_CFG:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  678  			/* disable all while restoring */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  679  			write_dc(par, i, 0);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  680  			break;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  681  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  682  		case DC_DV_CTL:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  683  			/* set all ram to dirty */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  684  			write_dc(par, i, par->dc[i] | DC_DV_CTL_CLEAR_DV_RAM);
2c3a1e49696fd05 drivers/video/fbdev/geode/lxfb_ops.c Gustavo A. R. Silva 2020-11-20  685  			break;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  686  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  687  		case DC_RSVD_1:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  688  		case DC_RSVD_2:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  689  		case DC_RSVD_3:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  690  		case DC_LINE_CNT:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  691  		case DC_PAL_ADDRESS:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  692  		case DC_PAL_DATA:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  693  		case DC_DFIFO_DIAG:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  694  		case DC_CFIFO_DIAG:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  695  		case DC_FILT_COEFF1:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  696  		case DC_FILT_COEFF2:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  697  		case DC_RSVD_4:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  698  		case DC_RSVD_5:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  699  			/* don't restore these registers */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  700  			break;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  701  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  702  		default:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  703  			write_dc(par, i, par->dc[i]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  704  		}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  705  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  706  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  707  	/* restore the palette */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  708  	write_dc(par, DC_PAL_ADDRESS, 0);
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  709  	for (i = 0; i < ARRAY_SIZE(par->dc_pal); i++)
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  710  		write_dc(par, DC_PAL_DATA, par->dc_pal[i]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  711  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  712  	/* restore the horizontal filter coefficients */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  713  	filt = par->dc[DC_IRQ_FILT_CTL] | DC_IRQ_FILT_CTL_H_FILT_SEL;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  714  	for (i = 0; i < ARRAY_SIZE(par->hcoeff); i += 2) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  715  		write_dc(par, DC_IRQ_FILT_CTL, (filt & 0xffffff00) | i);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  716  		write_dc(par, DC_FILT_COEFF1, par->hcoeff[i]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  717  		write_dc(par, DC_FILT_COEFF2, par->hcoeff[i + 1]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  718  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  719  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  720  	/* restore the vertical filter coefficients */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  721  	filt &= ~DC_IRQ_FILT_CTL_H_FILT_SEL;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  722  	for (i = 0; i < ARRAY_SIZE(par->vcoeff); i++) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  723  		write_dc(par, DC_IRQ_FILT_CTL, (filt & 0xffffff00) | i);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  724  		write_dc(par, DC_FILT_COEFF1, par->vcoeff[i]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  725  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  726  }
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  727  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  728  static void lx_restore_video_proc(struct lxfb_par *par)
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  729  {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  730  	int i;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  731  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  732  	wrmsrl(MSR_LX_GLD_MSR_CONFIG, par->msr.dfglcfg);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  733  	wrmsrl(MSR_LX_MSR_PADSEL, par->msr.padsel);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  734  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  735  	for (i = 0; i < ARRAY_SIZE(par->vp); i++) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  736  		switch (i) {
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  737  		case VP_VCFG:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  738  		case VP_DCFG:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  739  		case VP_PAR:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  740  		case VP_PDR:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  741  		case VP_CCS:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  742  		case VP_RSVD_0:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  743  		/* case VP_VDC: */ /* why should this not be restored? */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  744  		case VP_RSVD_1:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  745  		case VP_CRC32:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  746  			/* don't restore these registers */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  747  			break;
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  748  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  749  		default:
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  750  			write_vp(par, i, par->vp[i]);
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  751  		}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  752  	}
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  753  
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  754  	/* restore video processor palette */
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  755  	write_vp(par, VP_PAR, 0);
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  756  	for (i = 0; i < ARRAY_SIZE(par->vp_pal); i++)
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  757  		write_vp(par, VP_PDR, par->vp_pal[i]);
16cdd4336fdca9b drivers/video/geode/lxfb_ops.c       Daniel Drake        2010-11-30  758  
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  759  	/* restore video coeff ram */
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28 @760  	memcpy(par->vp_regs + VP_VCR, par->vp_coeff, sizeof(par->vp_coeff));
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  761  }
f694e53bd0db695 drivers/video/geode/lxfb_ops.c       Andres Salomon      2008-04-28  762  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
  2021-12-14 15:46       ` Kalle Valo
@ 2021-12-14 17:05         ` Kees Cook
  -1 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-14 17:05 UTC (permalink / raw)
  To: Kalle Valo
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

On Tue, Dec 14, 2021 at 05:46:31PM +0200, Kalle Valo wrote:
> Kalle Valo <kvalo@kernel.org> writes:
> 
> > Kees Cook <keescook@chromium.org> writes:
> >
> >> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> >> field bounds checking for memset(), avoid intentionally writing across
> >> neighboring fields.
> >>
> >> Use memset_startat() so memset() doesn't get confused about writing
> >> beyond the destination member that is intended to be the starting point
> >> of zeroing through the end of the struct. Additionally split up a later
> >> field-spanning memset() so that memset() can reason about the size.
> >>
> >> Cc: Kalle Valo <kvalo@codeaurora.org>
> >> Cc: "David S. Miller" <davem@davemloft.net>
> >> Cc: Jakub Kicinski <kuba@kernel.org>
> >> Cc: ath11k@lists.infradead.org
> >> Cc: linux-wireless@vger.kernel.org
> >> Cc: netdev@vger.kernel.org
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >
> > What's the plan for this patch? I would like to take this via my ath
> > tree to avoid conflicts.
> 
> Actually this has been already applied:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=d5549e9a6b86
> 
> Why are you submitting the same patch twice?

These are all part of a topic branch, and the cover letter mentioned
that a set of them have already been taken but haven't appeared in -next
(which was delayed).

Sorry for the confusion!

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
@ 2021-12-14 17:05         ` Kees Cook
  0 siblings, 0 replies; 43+ messages in thread
From: Kees Cook @ 2021-12-14 17:05 UTC (permalink / raw)
  To: Kalle Valo
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

On Tue, Dec 14, 2021 at 05:46:31PM +0200, Kalle Valo wrote:
> Kalle Valo <kvalo@kernel.org> writes:
> 
> > Kees Cook <keescook@chromium.org> writes:
> >
> >> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> >> field bounds checking for memset(), avoid intentionally writing across
> >> neighboring fields.
> >>
> >> Use memset_startat() so memset() doesn't get confused about writing
> >> beyond the destination member that is intended to be the starting point
> >> of zeroing through the end of the struct. Additionally split up a later
> >> field-spanning memset() so that memset() can reason about the size.
> >>
> >> Cc: Kalle Valo <kvalo@codeaurora.org>
> >> Cc: "David S. Miller" <davem@davemloft.net>
> >> Cc: Jakub Kicinski <kuba@kernel.org>
> >> Cc: ath11k@lists.infradead.org
> >> Cc: linux-wireless@vger.kernel.org
> >> Cc: netdev@vger.kernel.org
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >
> > What's the plan for this patch? I would like to take this via my ath
> > tree to avoid conflicts.
> 
> Actually this has been already applied:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=d5549e9a6b86
> 
> Why are you submitting the same patch twice?

These are all part of a topic branch, and the cover letter mentioned
that a set of them have already been taken but haven't appeared in -next
(which was delayed).

Sorry for the confusion!

-- 
Kees Cook

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
                     ` (3 preceding siblings ...)
  2021-12-14 16:32   ` kernel test robot
@ 2021-12-14 19:06   ` kernel test robot
  2021-12-16  8:56   ` kernel test robot
  2021-12-16 11:08   ` Mark Rutland
  6 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-14 19:06 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5 next-20211213]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-m021-20211214 (https://download.01.org/0day-ci/archive/20211215/202112150326.Cu6pK9ir-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

New smatch warnings:
drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3289 pvr2_hdw_get_tuner_status() warn: inconsistent indenting

Old smatch warnings:
drivers/media/usb/pvrusb2/pvrusb2-hdw.c:1730 pvr2_hdw_set_streaming() warn: inconsistent indenting
drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3461 pvr2_hdw_cpufw_set_enabled() warn: inconsistent indenting
drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3501 pvr2_hdw_cpufw_get() warn: inconsistent indenting

vim +3289 drivers/media/usb/pvrusb2/pvrusb2-hdw.c

432907f750b27aa drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2008-08-31  3279  
432907f750b27aa drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2008-08-31  3280  
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3281  /* Return information about the tuner */
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3282  int pvr2_hdw_get_tuner_status(struct pvr2_hdw *hdw,struct v4l2_tuner *vtp)
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3283  {
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3284  	LOCK_TAKE(hdw->big_lock); do {
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3285  		if (hdw->tuner_signal_stale) {
a51f5000b791003 drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2009-03-06  3286  			pvr2_hdw_status_poll(hdw);
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3287  		}
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3288  		memcpy(vtp,&hdw->tuner_signal_info,sizeof(struct v4l2_tuner));
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20 @3289  	} while (0); LOCK_GIVE(hdw->big_lock);
18103c57b0168eb drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2007-01-20  3290  	return 0;
d855497edbfbf9e drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2006-06-26  3291  }
d855497edbfbf9e drivers/media/video/pvrusb2/pvrusb2-hdw.c Mike Isely 2006-06-26  3292  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 00/17] Enable strict compile-time memcpy() fortify checks
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (16 preceding siblings ...)
  2021-12-13 22:33 ` [PATCH 17/17] fortify: Work around Clang inlining bugs Kees Cook
@ 2021-12-15  0:26 ` Jason Gunthorpe
  2021-12-17  4:04 ` Martin K. Petersen
  18 siblings, 0 replies; 43+ messages in thread
From: Jason Gunthorpe @ 2021-12-15  0:26 UTC (permalink / raw)
  To: Kees Cook; +Cc: linux-hardening, linux-kernel

On Mon, Dec 13, 2021 at 02:33:14PM -0800, Kees Cook wrote:
> Hi,
> 
> This is "phase 2" (of several phases) to hardening the kernel against
> memcpy-based buffer overflows. With nearly all compile-time fixes
> landed, the next step is to turn on the warning globally to keep future
> compile-time issues from happening, and let us take the step towards
> run-time checking (and towards a new API for flexible array structures).
> 
> This series is based on latest linux-next, and several patches here
> have already been taken by subsystem maintainers but haven't appeared
> in linux-next yet, and are noted below.

I took the RDMA patches to the rdma tree:

>     RDMA/mlx5: Use memset_after() to zero struct mlx5_ib_mr
>     iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl
>     IB/mthca: Use memset_startat() for clearing mpt_entry

I needed rc5 to come out before I could take the mlx5 patch

Thanks,
Jason

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
                     ` (4 preceding siblings ...)
  2021-12-14 19:06   ` kernel test robot
@ 2021-12-16  8:56   ` kernel test robot
  2021-12-16 11:08   ` Mark Rutland
  6 siblings, 0 replies; 43+ messages in thread
From: kernel test robot @ 2021-12-16  8:56 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 9323 bytes --]

Hi Kees,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.16-rc5 next-20211215]
[cannot apply to rdma/for-next axboe-block/for-next kvm/queue tip/x86/core mkp-scsi/for-next jejb-scsi/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git aa50faff4416c869b52dff68a937c84d29e12f4b
config: i386-randconfig-s002-20211216 (https://download.01.org/0day-ci/archive/20211216/202112161632.BTEfICUX-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.4-dirty
        # https://github.com/0day-ci/linux/commit/80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Kees-Cook/Enable-strict-compile-time-memcpy-fortify-checks/20211214-064002
        git checkout 80c8d2aae95aae6bd09e3ef84b74d0afe631abae
        # save the config file to linux build tree
        mkdir build_dir
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash drivers/video/fbdev/geode/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *gp_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse:     got void [noderef] __iomem *gp_regs
>> drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *gp_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse:     got void [noderef] __iomem *gp_regs
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *gp_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:30:9: sparse:     got void [noderef] __iomem *gp_regs
>> drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *dc_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse:     got void [noderef] __iomem *dc_regs
>> drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *dc_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse:     got void [noderef] __iomem *dc_regs
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *dc_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:31:9: sparse:     got void [noderef] __iomem *dc_regs
>> drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *vid_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse:     got void [noderef] __iomem *vid_regs
>> drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *vid_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse:     got void [noderef] __iomem *vid_regs
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem *vid_regs @@
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:32:9: sparse:     got void [noderef] __iomem *vid_regs
>> drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse:     got void [noderef] __iomem *
>> drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse:     got void [noderef] __iomem *
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse: sparse: incorrect type in argument 2 (different address spaces) @@     expected void const * @@     got void [noderef] __iomem * @@
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse:     expected void const *
   drivers/video/fbdev/geode/suspend_gx.c:33:9: sparse:     got void [noderef] __iomem *

vim +30 drivers/video/fbdev/geode/suspend_gx.c

46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  13  
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  14  static void gx_save_regs(struct gxfb_par *par)
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  15  {
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  16  	int i;
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  17  
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  18  	/* wait for the BLT engine to stop being busy */
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  19  	do {
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  20  		i = read_gp(par, GP_BLT_STATUS);
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  21  	} while (i & (GP_BLT_STATUS_BLT_PENDING | GP_BLT_STATUS_BLT_BUSY));
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  22  
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  23  	/* save MSRs */
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  24  	rdmsrl(MSR_GX_MSR_PADSEL, par->msr.padsel);
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  25  	rdmsrl(MSR_GLCP_DOTPLL, par->msr.dotpll);
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  26  
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  27  	write_dc(par, DC_UNLOCK, DC_UNLOCK_UNLOCK);
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  28  
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  29  	/* save registers */
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28 @30  	memcpy(par->gp, par->gp_regs, sizeof(par->gp));
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28 @31  	memcpy(par->dc, par->dc_regs, sizeof(par->dc));
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28 @32  	memcpy(par->vp, par->vid_regs, sizeof(par->vp));
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28 @33  	memcpy(par->fp, par->vid_regs + VP_FP_START, sizeof(par->fp));
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  34  
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  35  	/* save the palette */
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  36  	write_dc(par, DC_PAL_ADDRESS, 0);
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  37  	for (i = 0; i < ARRAY_SIZE(par->pal); i++)
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  38  		par->pal[i] = read_dc(par, DC_PAL_DATA);
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  39  }
46fb6f110dfc3f drivers/video/geode/suspend_gx.c Andres Salomon 2008-04-28  40  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
                     ` (5 preceding siblings ...)
  2021-12-16  8:56   ` kernel test robot
@ 2021-12-16 11:08   ` Mark Rutland
  2021-12-16 11:21     ` Mark Rutland
  2021-12-16 18:00     ` Kees Cook
  6 siblings, 2 replies; 43+ messages in thread
From: Mark Rutland @ 2021-12-16 11:08 UTC (permalink / raw)
  To: Kees Cook; +Cc: linux-hardening, linux-kernel

On Mon, Dec 13, 2021 at 02:33:20PM -0800, Kees Cook wrote:
> memcpy() is dead; long live memcpy()
> 
> tl;dr: In order to eliminate a large class of common buffer overflow
> flaws that continue to persist in the kernel, have memcpy() (under
> CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct
> member when they have a known size. This would have caught all of the
> memcpy()-related buffer write overflow flaws identified in at least the
> last three years.
> 

Hi Kees,

Since there's a *lot* of context below, it's very easy to miss some key details
(e.g. that the compile-time warnings are limited to W=1 builds). It would be
really nice if the summary above could say something like:

  This patch makes it possible to detect when memcpy() of a struct member may
  go past the bounds of that member. When CONFIG_FORTIFY_SOURCE=y, runtime
  checks are always emitted where the compiler cannot guarantee a memcpy() is
  safely bounded, and compile-time warnings are enabled for W=1 builds.

  This catches a large class of common buffer overflow flaws, and would have
  caught all of the memcpy()-related buffer write overflow flaws identified in
  the last three years.

As an aside, since W=1 is chock-full of (IMO useless) warnings, is there any
way to enable *just* the FORTIFY_SOURCE warnings?

[...]

> Implementation:
> 
> Tighten the memcpy() destination buffer size checking to use the actual
> ("mode 1") target buffer size as the bounds check instead of their
> enclosing structure's ("mode 0") size. Use a common inline for memcpy()
> (and memmove() in a following patch), since all the tests are the
> same. All new cross-field memcpy() uses must use the struct_group() macro
> or similar to target a specific range of fields, so that FORTIFY_SOURCE
> can reason about the size and safety of the copy.
> 
> For now, cross-member "mode 1" read detection at compile-time will be
> limited to W=1 builds, since it is, unfortunately, very common. As the
> priority is solving write overflows, read overflows can be part of the
> next phase.

I had a go at testing this on arm64, and could get build-time warnings from GCC
11.1.0, but not from Clang 13.0.0.

I picked the series from:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=memcpy/step2/next-20211213

I prepped a tree with that branch and a deliberate bug:

| [mark@lakrids:~/src/linux]% git checkout -f kernel-org-kees/memcpy/step2/next-20211213
| [mark@lakrids:~/src/linux]% git clean -qfdx
| [mark@lakrids:~/src/linux]% cat <<EOF >> arch/arm64/kernel/setup.c
| 
| struct foo {
|        int a;
|        int b;
| } foo1, foo2;
| 
| void foo_copy(void);
| void foo_copy(void)
| {
|        memcpy(&foo1.a, &foo2.a, sizeof(foo1));
| }
| EOF

When building with GCC 11.1.0:

| [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -s defconfig
| [mark@lakrids:~/src/linux]% ./scripts/config -e FORTIFY_SOURCE                                      
| [mark@lakrids:~/src/linux]% grep FORTIFY_SOURCE .config       
| CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
| CONFIG_FORTIFY_SOURCE=y
| [mark@lakrids:~/src/linux]% usekorg 11.1.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- -s arch/arm64/kernel/setup.o
| In file included from ./include/linux/string.h:253,
|                  from ./include/linux/bitmap.h:11,
|                  from ./include/linux/cpumask.h:12,
|                  from ./include/linux/smp.h:13,
|                  from ./include/linux/lockdep.h:14,
|                  from ./include/linux/mutex.h:17,
|                  from ./include/linux/kernfs.h:12,
|                  from ./include/linux/sysfs.h:16,
|                  from ./include/linux/kobject.h:20,
|                  from ./include/linux/of.h:17,
|                  from ./include/linux/irqdomain.h:35,
|                  from ./include/linux/acpi.h:13,
|                  from arch/arm64/kernel/setup.c:9:
| In function 'fortify_memcpy_chk',
|     inlined from 'foo_copy' at arch/arm64/kernel/setup.c:457:8:
| ./include/linux/fortify-string.h:316:25: warning: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning]
|   316 |                         __write_overflow_field(p_size_field, size);
|       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ./include/linux/fortify-string.h:324:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning]
|   324 |                         __read_overflow2_field(q_size_field, size);
|       |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When building with clang 13.0.0 (the vdso bits can be ignored):

| [mark@lakrids:~/src/linux]% usellvm 13.0.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- LLVM=1 -s defconfig                    
| [mark@lakrids:~/src/linux]% ./scripts/config -e FORTIFY_SOURCE                                             
| [mark@lakrids:~/src/linux]% grep FORTIFY_SOURCE .config       
| CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
| CONFIG_FORTIFY_SOURCE=y
| [mark@lakrids:~/src/linux]% usellvm 13.0.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- LLVM=1 W=1 -s arch/arm64/kernel/setup.o
| arch/arm64/kernel/vdso/vgettimeofday.c:9:5: warning: no previous prototype for function '__kernel_clock_gettime' [-Wmissing-prototypes]
| int __kernel_clock_gettime(clockid_t clock,
|     ^
| arch/arm64/kernel/vdso/vgettimeofday.c:9:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
| int __kernel_clock_gettime(clockid_t clock,
| ^
| static 
| arch/arm64/kernel/vdso/vgettimeofday.c:15:5: warning: no previous prototype for function '__kernel_gettimeofday' [-Wmissing-prototypes]
| int __kernel_gettimeofday(struct __kernel_old_timeval *tv,
|     ^
| arch/arm64/kernel/vdso/vgettimeofday.c:15:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
| int __kernel_gettimeofday(struct __kernel_old_timeval *tv,
| ^
| static 
| arch/arm64/kernel/vdso/vgettimeofday.c:21:5: warning: no previous prototype for function '__kernel_clock_getres' [-Wmissing-prototypes]
| int __kernel_clock_getres(clockid_t clock_id,
|     ^
| arch/arm64/kernel/vdso/vgettimeofday.c:21:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
| int __kernel_clock_getres(clockid_t clock_id,
| ^
| static 
| 3 warnings generated.

No relevant warnings, but code was generated for runtime warnings:

| 0000000000000000 <foo_copy>:
|    0:   d503233f        paciasp
|    4:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
|    8:   910003fd        mov     x29, sp
|    c:   52800080        mov     w0, #0x4                        // #4
|   10:   52800101        mov     w1, #0x8                        // #8
|   14:   94000000        bl      0 <__write_overflow_field>
|   18:   52800080        mov     w0, #0x4                        // #4
|   1c:   52800101        mov     w1, #0x8                        // #8
|   20:   94000000        bl      0 <__read_overflow2_field>
|   24:   90000008        adrp    x8, 8 <foo_copy+0x8>
|   28:   f9400108        ldr     x8, [x8]
|   2c:   90000009        adrp    x9, 0 <foo_copy>
|   30:   f9000128        str     x8, [x9]
|   34:   a8c17bfd        ldp     x29, x30, [sp], #16
|   38:   d50323bf        autiasp
|   3c:   d65f03c0        ret

Have I misunderstood how that's meant to work, or am I doing something wrong?

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-16 11:08   ` Mark Rutland
@ 2021-12-16 11:21     ` Mark Rutland
  2021-12-16 18:00     ` Kees Cook
  1 sibling, 0 replies; 43+ messages in thread
From: Mark Rutland @ 2021-12-16 11:21 UTC (permalink / raw)
  To: Kees Cook; +Cc: linux-hardening, linux-kernel

On Thu, Dec 16, 2021 at 11:08:26AM +0000, Mark Rutland wrote:
> On Mon, Dec 13, 2021 at 02:33:20PM -0800, Kees Cook wrote:
> > memcpy() is dead; long live memcpy()
> > 
> > tl;dr: In order to eliminate a large class of common buffer overflow
> > flaws that continue to persist in the kernel, have memcpy() (under
> > CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct
> > member when they have a known size. This would have caught all of the
> > memcpy()-related buffer write overflow flaws identified in at least the
> > last three years.
> > 
> 
> Hi Kees,
> 
> Since there's a *lot* of context below, it's very easy to miss some key details
> (e.g. that the compile-time warnings are limited to W=1 builds). It would be
> really nice if the summary above could say something like:
> 
>   This patch makes it possible to detect when memcpy() of a struct member may
>   go past the bounds of that member. When CONFIG_FORTIFY_SOURCE=y, runtime
>   checks are always emitted where the compiler cannot guarantee a memcpy() is
>   safely bounded, and compile-time warnings are enabled for W=1 builds.
> 
>   This catches a large class of common buffer overflow flaws, and would have
>   caught all of the memcpy()-related buffer write overflow flaws identified in
>   the last three years.
> 
> As an aside, since W=1 is chock-full of (IMO useless) warnings, is there any
> way to enable *just* the FORTIFY_SOURCE warnings?
> 
> [...]
> 
> > Implementation:
> > 
> > Tighten the memcpy() destination buffer size checking to use the actual
> > ("mode 1") target buffer size as the bounds check instead of their
> > enclosing structure's ("mode 0") size. Use a common inline for memcpy()
> > (and memmove() in a following patch), since all the tests are the
> > same. All new cross-field memcpy() uses must use the struct_group() macro
> > or similar to target a specific range of fields, so that FORTIFY_SOURCE
> > can reason about the size and safety of the copy.
> > 
> > For now, cross-member "mode 1" read detection at compile-time will be
> > limited to W=1 builds, since it is, unfortunately, very common. As the
> > priority is solving write overflows, read overflows can be part of the
> > next phase.
> 
> I had a go at testing this on arm64, and could get build-time warnings from GCC
> 11.1.0, but not from Clang 13.0.0.

Looking again, I see this is down to __compiletime_warning() only being usable
from clang 14.0 onwards (and the final patch mentions that in passing), so I
guess that's expected.

It would be nice to call that out somewhere in this patch (e.g. in that
introductory paragraph), since it's very each to miss that and get confused...
;)

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
  2021-12-14 17:05         ` Kees Cook
@ 2021-12-16 13:50           ` Kalle Valo
  -1 siblings, 0 replies; 43+ messages in thread
From: Kalle Valo @ 2021-12-16 13:50 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

Kees Cook <keescook@chromium.org> writes:

> On Tue, Dec 14, 2021 at 05:46:31PM +0200, Kalle Valo wrote:
>> Kalle Valo <kvalo@kernel.org> writes:
>> 
>> > Kees Cook <keescook@chromium.org> writes:
>> >
>> >> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> >> field bounds checking for memset(), avoid intentionally writing across
>> >> neighboring fields.
>> >>
>> >> Use memset_startat() so memset() doesn't get confused about writing
>> >> beyond the destination member that is intended to be the starting point
>> >> of zeroing through the end of the struct. Additionally split up a later
>> >> field-spanning memset() so that memset() can reason about the size.
>> >>
>> >> Cc: Kalle Valo <kvalo@codeaurora.org>
>> >> Cc: "David S. Miller" <davem@davemloft.net>
>> >> Cc: Jakub Kicinski <kuba@kernel.org>
>> >> Cc: ath11k@lists.infradead.org
>> >> Cc: linux-wireless@vger.kernel.org
>> >> Cc: netdev@vger.kernel.org
>> >> Signed-off-by: Kees Cook <keescook@chromium.org>
>> >
>> > What's the plan for this patch? I would like to take this via my ath
>> > tree to avoid conflicts.
>> 
>> Actually this has been already applied:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=d5549e9a6b86
>> 
>> Why are you submitting the same patch twice?
>
> These are all part of a topic branch, and the cover letter mentioned
> that a set of them have already been taken but haven't appeared in -next
> (which was delayed).

Do note that some wireless drivers (at least ath, mt76 and iwlwifi) are
maintained in separate trees, so don't be surprised if it takes several
weeks before they are visible in linux-next.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors
@ 2021-12-16 13:50           ` Kalle Valo
  0 siblings, 0 replies; 43+ messages in thread
From: Kalle Valo @ 2021-12-16 13:50 UTC (permalink / raw)
  To: Kees Cook
  Cc: linux-hardening, David S. Miller, Jakub Kicinski, ath11k,
	linux-wireless, netdev, linux-kernel

Kees Cook <keescook@chromium.org> writes:

> On Tue, Dec 14, 2021 at 05:46:31PM +0200, Kalle Valo wrote:
>> Kalle Valo <kvalo@kernel.org> writes:
>> 
>> > Kees Cook <keescook@chromium.org> writes:
>> >
>> >> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> >> field bounds checking for memset(), avoid intentionally writing across
>> >> neighboring fields.
>> >>
>> >> Use memset_startat() so memset() doesn't get confused about writing
>> >> beyond the destination member that is intended to be the starting point
>> >> of zeroing through the end of the struct. Additionally split up a later
>> >> field-spanning memset() so that memset() can reason about the size.
>> >>
>> >> Cc: Kalle Valo <kvalo@codeaurora.org>
>> >> Cc: "David S. Miller" <davem@davemloft.net>
>> >> Cc: Jakub Kicinski <kuba@kernel.org>
>> >> Cc: ath11k@lists.infradead.org
>> >> Cc: linux-wireless@vger.kernel.org
>> >> Cc: netdev@vger.kernel.org
>> >> Signed-off-by: Kees Cook <keescook@chromium.org>
>> >
>> > What's the plan for this patch? I would like to take this via my ath
>> > tree to avoid conflicts.
>> 
>> Actually this has been already applied:
>> 
>> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=d5549e9a6b86
>> 
>> Why are you submitting the same patch twice?
>
> These are all part of a topic branch, and the cover letter mentioned
> that a set of them have already been taken but haven't appeared in -next
> (which was delayed).

Do note that some wireless drivers (at least ath, mt76 and iwlwifi) are
maintained in separate trees, so don't be surprised if it takes several
weeks before they are visible in linux-next.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

-- 
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-16 11:08   ` Mark Rutland
  2021-12-16 11:21     ` Mark Rutland
@ 2021-12-16 18:00     ` Kees Cook
  2021-12-17 13:34       ` Mark Rutland
  1 sibling, 1 reply; 43+ messages in thread
From: Kees Cook @ 2021-12-16 18:00 UTC (permalink / raw)
  To: Mark Rutland; +Cc: linux-hardening, linux-kernel

On Thu, Dec 16, 2021 at 11:08:26AM +0000, Mark Rutland wrote:
> On Mon, Dec 13, 2021 at 02:33:20PM -0800, Kees Cook wrote:
> > memcpy() is dead; long live memcpy()
> > 
> > tl;dr: In order to eliminate a large class of common buffer overflow
> > flaws that continue to persist in the kernel, have memcpy() (under
> > CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct
> > member when they have a known size. This would have caught all of the
> > memcpy()-related buffer write overflow flaws identified in at least the
> > last three years.
> > 
> 
> Hi Kees,
> 
> Since there's a *lot* of context below, it's very easy to miss some key details
> (e.g. that the compile-time warnings are limited to W=1 builds). It would be
> really nice if the summary above could say something like:

Hm, I do need to write a better summary! I think there's still some
misunderstanding, and I will attempt some clarity here... :)

> 
>   This patch makes it possible to detect when memcpy() of a struct member may
>   go past the bounds of that member. When CONFIG_FORTIFY_SOURCE=y, runtime
>   checks are always emitted where the compiler cannot guarantee a memcpy() is
>   safely bounded, and compile-time warnings are enabled for W=1 builds.

For GCC and Clang 14, compile-time _write_ overflow warnings are meant
to be emitted under FORTIFY_SOURCE. _read_ overflow warnings are meant
to be emitted under FORTIFY_SOURCE + W=1 (or when the same statement
also has a write overflow).

> 
>   This catches a large class of common buffer overflow flaws, and would have
>   caught all of the memcpy()-related buffer write overflow flaws identified in
>   the last three years.
> 
> As an aside, since W=1 is chock-full of (IMO useless) warnings, is there any
> way to enable *just* the FORTIFY_SOURCE warnings?

To see them all (i.e. not shove some into W=1), you can remove the "W=1
or write overflow" part of the read overflow test in fortify-string.h.
e.g.:

-                if ((IS_ENABLED(KBUILD_EXTRA_WARN1) || p_size_field < size) &&
-                    q_size_field < size)
+                if (q_size_field < size)

> I had a go at testing this on arm64, and could get build-time warnings from GCC
> 11.1.0, but not from Clang 13.0.0.

This is correct and expected due to Clang 13's lack of support for
compiletime_warning().

> No relevant warnings, but code was generated for runtime warnings:
> 
> | 0000000000000000 <foo_copy>:
> |    0:   d503233f        paciasp
> |    4:   a9bf7bfd        stp     x29, x30, [sp, #-16]!
> |    8:   910003fd        mov     x29, sp
> |    c:   52800080        mov     w0, #0x4                        // #4
> |   10:   52800101        mov     w1, #0x8                        // #8
> |   14:   94000000        bl      0 <__write_overflow_field>
> |   18:   52800080        mov     w0, #0x4                        // #4
> |   1c:   52800101        mov     w1, #0x8                        // #8
> |   20:   94000000        bl      0 <__read_overflow2_field>
> |   24:   90000008        adrp    x8, 8 <foo_copy+0x8>
> |   28:   f9400108        ldr     x8, [x8]
> |   2c:   90000009        adrp    x9, 0 <foo_copy>
> |   30:   f9000128        str     x8, [x9]
> |   34:   a8c17bfd        ldp     x29, x30, [sp], #16
> |   38:   d50323bf        autiasp
> |   3c:   d65f03c0        ret
> 
> Have I misunderstood how that's meant to work, or am I doing something wrong?

The generally stated requirement from Linus for these kinds of
kernel changes was to never break the build (i.e. we cannot use
compiletime_error() -- which Clang 13 falls back to with a link-time
failure).

Since this phase of the series is only compile-time warnings (not the
run-time warnings), it's rather a no-op for Clang 13. However, the final
patch in the series brings the earlier ("mode 0") FORTIFY behaviors to
Clang finally.

Clang 14 implements compiletime_warning(), so in that situation, the
warnings appear.

It's a pretty wacky Venn Diagram, and I will attempt to include some
sort of illustration for it, as the behavioral differences are complex.

-Kees

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 00/17] Enable strict compile-time memcpy() fortify checks
  2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
                   ` (17 preceding siblings ...)
  2021-12-15  0:26 ` [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Jason Gunthorpe
@ 2021-12-17  4:04 ` Martin K. Petersen
  18 siblings, 0 replies; 43+ messages in thread
From: Martin K. Petersen @ 2021-12-17  4:04 UTC (permalink / raw)
  To: Kees Cook, linux-hardening; +Cc: Martin K . Petersen, linux-kernel

On Mon, 13 Dec 2021 14:33:14 -0800, Kees Cook wrote:

> This is "phase 2" (of several phases) to hardening the kernel against
> memcpy-based buffer overflows. With nearly all compile-time fixes
> landed, the next step is to turn on the warning globally to keep future
> compile-time issues from happening, and let us take the step towards
> run-time checking (and towards a new API for flexible array structures).
> 
> This series is based on latest linux-next, and several patches here
> have already been taken by subsystem maintainers but haven't appeared
> in linux-next yet, and are noted below.
> 
> [...]

Applied to 5.17/scsi-queue, thanks!

[15/17] scsi: lpfc: Use struct_group() to initialize struct lpfc_cgn_info
        https://git.kernel.org/mkp/scsi/c/532adda9f405

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time
  2021-12-16 18:00     ` Kees Cook
@ 2021-12-17 13:34       ` Mark Rutland
  0 siblings, 0 replies; 43+ messages in thread
From: Mark Rutland @ 2021-12-17 13:34 UTC (permalink / raw)
  To: Kees Cook; +Cc: linux-hardening, linux-kernel

On Thu, Dec 16, 2021 at 10:00:09AM -0800, Kees Cook wrote:
> On Thu, Dec 16, 2021 at 11:08:26AM +0000, Mark Rutland wrote:
> > On Mon, Dec 13, 2021 at 02:33:20PM -0800, Kees Cook wrote:
> > > memcpy() is dead; long live memcpy()
> > > 
> > > tl;dr: In order to eliminate a large class of common buffer overflow
> > > flaws that continue to persist in the kernel, have memcpy() (under
> > > CONFIG_FORTIFY_SOURCE) perform bounds checking of the destination struct
> > > member when they have a known size. This would have caught all of the
> > > memcpy()-related buffer write overflow flaws identified in at least the
> > > last three years.
> > > 
> > 
> > Hi Kees,
> > 
> > Since there's a *lot* of context below, it's very easy to miss some key details
> > (e.g. that the compile-time warnings are limited to W=1 builds). It would be
> > really nice if the summary above could say something like:
> 
> Hm, I do need to write a better summary! I think there's still some
> misunderstanding, and I will attempt some clarity here... :)

Thanks! Sorry if that came across as a complaint; this looks really useful and
I just couldn't figure out if I was holding things wrong or whether I was
hitting an unexpected issue. :)

> >   This patch makes it possible to detect when memcpy() of a struct member may
> >   go past the bounds of that member. When CONFIG_FORTIFY_SOURCE=y, runtime
> >   checks are always emitted where the compiler cannot guarantee a memcpy() is
> >   safely bounded, and compile-time warnings are enabled for W=1 builds.
> 
> For GCC and Clang 14, compile-time _write_ overflow warnings are meant
> to be emitted under FORTIFY_SOURCE. _read_ overflow warnings are meant
> to be emitted under FORTIFY_SOURCE + W=1 (or when the same statement
> also has a write overflow).

Cool.

I'll await a clang 14 release, or go build my own copy in the mean time.

> >   This catches a large class of common buffer overflow flaws, and would have
> >   caught all of the memcpy()-related buffer write overflow flaws identified in
> >   the last three years.
> > 
> > As an aside, since W=1 is chock-full of (IMO useless) warnings, is there any
> > way to enable *just* the FORTIFY_SOURCE warnings?
> 
> To see them all (i.e. not shove some into W=1), you can remove the "W=1
> or write overflow" part of the read overflow test in fortify-string.h.
> e.g.:
> 
> -                if ((IS_ENABLED(KBUILD_EXTRA_WARN1) || p_size_field < size) &&
> -                    q_size_field < size)
> +                if (q_size_field < size)
> 
> > I had a go at testing this on arm64, and could get build-time warnings from GCC
> > 11.1.0, but not from Clang 13.0.0.
> 
> This is correct and expected due to Clang 13's lack of support for
> compiletime_warning().

Thanks for confirming!

Thanks,
Mark.

^ permalink raw reply	[flat|nested] 43+ messages in thread
end of thread, other threads:[~2021-12-17 13:34 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-13 22:33 [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Kees Cook
2021-12-13 22:33 ` [PATCH 01/17] KVM: x86: Replace memset() "optimization" with normal per-field writes Kees Cook
2021-12-13 22:33 ` [PATCH 02/17] net/mlx5e: Avoid field-overflowing memcpy() Kees Cook
2021-12-13 22:33 ` [PATCH 03/17] net/mlx5e: Use struct_group() for memcpy() region Kees Cook
2021-12-13 22:33 ` [PATCH 04/17] media: omap3isp: " Kees Cook
2021-12-13 22:33 ` [PATCH 05/17] sata_fsl: " Kees Cook
2021-12-13 22:33 ` [PATCH 06/17] fortify: Detect struct member overflows in memcpy() at compile-time Kees Cook
2021-12-14  3:56   ` kernel test robot
2021-12-14  8:46   ` kernel test robot
2021-12-14 11:50   ` kernel test robot
2021-12-14 16:32   ` kernel test robot
2021-12-14 19:06   ` kernel test robot
2021-12-16  8:56   ` kernel test robot
2021-12-16 11:08   ` Mark Rutland
2021-12-16 11:21     ` Mark Rutland
2021-12-16 18:00     ` Kees Cook
2021-12-17 13:34       ` Mark Rutland
2021-12-13 22:33 ` [PATCH 07/17] fortify: Detect struct member overflows in memmove() " Kees Cook
2021-12-13 22:33 ` [PATCH 08/17] ath11k: Use memset_startat() for clearing queue descriptors Kees Cook
2021-12-13 22:33   ` Kees Cook
2021-12-14  6:02   ` Kalle Valo
2021-12-14  6:02     ` Kalle Valo
2021-12-14 15:46     ` Kalle Valo
2021-12-14 15:46       ` Kalle Valo
2021-12-14 17:05       ` Kees Cook
2021-12-14 17:05         ` Kees Cook
2021-12-16 13:50         ` Kalle Valo
2021-12-16 13:50           ` Kalle Valo
2021-12-13 22:33 ` [PATCH 09/17] RDMA/mlx5: Use memset_after() to zero struct mlx5_ib_mr Kees Cook
2021-12-13 22:33 ` [PATCH 10/17] drbd: Use struct_group() to zero algs Kees Cook
2021-12-13 22:33 ` [PATCH 11/17] dm integrity: Use struct_group() to zero struct journal_sector Kees Cook
2021-12-13 22:33   ` [dm-devel] " Kees Cook
2021-12-13 22:33 ` [PATCH 12/17] iw_cxgb4: Use memset_startat() for cpl_t5_pass_accept_rpl Kees Cook
2021-12-13 22:33 ` [PATCH 13/17] intel_th: msu: Use memset_startat() for clearing hw header Kees Cook
2021-12-13 22:33 ` [PATCH 14/17] IB/mthca: Use memset_startat() for clearing mpt_entry Kees Cook
2021-12-13 22:33 ` [PATCH 15/17] scsi: lpfc: Use struct_group() to initialize struct lpfc_cgn_info Kees Cook
2021-12-13 22:33 ` [PATCH 16/17] fortify: Detect struct member overflows in memset() at compile-time Kees Cook
2021-12-14 12:31   ` kernel test robot
2021-12-13 22:33 ` [PATCH 17/17] fortify: Work around Clang inlining bugs Kees Cook
2021-12-14 13:22   ` kernel test robot
2021-12-14 13:22     ` kernel test robot
2021-12-15  0:26 ` [PATCH 00/17] Enable strict compile-time memcpy() fortify checks Jason Gunthorpe
2021-12-17  4:04 ` Martin K. Petersen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.