Re: Designated initializers, struct randomization and addressing?
On Wed, Jan 4, 2017 at 8:55 AM, Stephen Hemminger wrote: > On Tue, 3 Jan 2017 22:35:26 -0800 > Kees Cook wrote: > >> For randstruct and constify, the automatic selection is done on >> structures with only function pointers. (Additional structures can be >> added via a compiler attribute marking.) >> >> See is_pure_ops_struct(): > > Is there anyway to use this plugin to identify pure_ops structures not > already marked as const? That's what the constify plugin does, yes. Though to deal with cases where something rarely written to, the pax_open_kernel/pax_close_kernel annotations are needed, which is why I don't have a sane port of the constify plugin yet. We need to build upstream-acceptable infrastructure for the write-rarely case. But, as Julia replied, yes, there's a huge list. :) -Kees -- Kees Cook Nexus Security
Re: Designated initializers, struct randomization and addressing?
On Wed, 4 Jan 2017, Stephen Hemminger wrote: > On Tue, 3 Jan 2017 22:35:26 -0800 > Kees Cook wrote: > > > For randstruct and constify, the automatic selection is done on > > structures with only function pointers. (Additional structures can be > > added via a compiler attribute marking.) > > > > See is_pure_ops_struct(): > > Is there anyway to use this plugin to identify pure_ops structures not > already marked as const? Here is a list collected with Coccinelle. The file names and the line numbers are the instances of non-const structures. julia vpbe_device_ops: drivers/media/platform/davinci/vpbe.c:797 mbus_hw_ops: drivers/misc/mic/host/mic_boot.c:374 drivers/misc/mic/card/mic_x100.c:237 fcoe_sysfs_function_template: drivers/scsi/fcoe/fcoe.c:160 drivers/scsi/bnx2fc/bnx2fc_fcoe.c:2812 nfc_phy_ops: drivers/nfc/st-nci/spi.c:220 drivers/nfc/st-nci/i2c.c:205 drm_bridge_funcs: drivers/gpu/drm/bridge/adv7511/adv7511_drv.c:831 prm_ll_data: arch/arm/mach-omap2/prm2xxx.c:214 arch/arm/mach-omap2/prm33xx.c:374 ptlrpc_sec_cops: drivers/staging/lustre/lustre/ptlrpc/sec_plain.c:969 drivers/staging/lustre/lustre/ptlrpc/sec_null.c:379 cfg80211_ops: drivers/net/wireless/intel/ipw2x00/libipw_module.c:66 fc_rport_operations: drivers/scsi/fcoe/fcoe_ctlr.c:2165 thermal_zone_of_device_ops: drivers/hwmon/scpi-hwmon.c:93 ui_helpline: tools/perf/ui/tui/helpline.c:51 skl_dsp_fw_ops: sound/soc/intel/skylake/bxt-sst.c:552 iomap_ops: fs/ext4/inode.c:3423 fs/xfs/xfs_iomap.c:1193 fs/xfs/xfs_iomap.c:1147 fs/ext2/inode.c:845 fpga_bridge_ops: drivers/fpga/altera-freeze-bridge.c:206 qlcnic_nic_template: drivers/net/ethernet/qlogic/qlcnic/qlcnic_sriov_common.c:82 emitter: scripts/dtc/flattree.c:107 scripts/dtc/flattree.c:233 hist_entry_ops: tools/perf/builtin-c2c.c:149 pccard_resource_ops: drivers/pcmcia/rsrc_mgr.c:61 mcfqspi_cs_control: arch/m68k/coldfire/device.c:308 z8530_irqhandler: drivers/net/wan/z85230.c:613 drivers/net/wan/z85230.c:486 drivers/net/wan/z85230.c:681 drivers/net/wan/z85230.c:607 snd_soc_dai_ops: sound/soc/pxa/mmp-sspa.c:384 sound/soc/codecs/max9867.c:354 sound/soc/codecs/msm8916-wcd-digital.c:791 sound/soc/codecs/rt5663.c:2861 drivers/staging/greybus/audio_codec.c:672 amba_pl010_data: arch/arm/mach-ep93xx/core.c:172 snd_pcm_ops: sound/sh/aica.c:439 sound/ppc/snd_ps3.c:775 sound/pci/au88x0/au88x0_pcm.c:442 sound/pci/sis7019.c:875 sound/pci/sis7019.c:886 sound/soc/au1x/dbdma2.c:307 sound/soc/blackfin/bf5xx-ac97-pcm.c:301 sound/soc/fsl/mpc5200_dma.c:290 sound/soc/pxa/pxa2xx-pcm.c:48 sound/arm/aaci.c:638 sound/arm/aaci.c:741 sound/arm/pxa2xx-pcm.c:71 sound/usb/caiaq/audio.c:341 sound/usb/line6/playback.c:396 sound/usb/hiface/pcm.c:516 sound/atmel/ac97c.c:628 sound/atmel/ac97c.c:639 sound/isa/sb/sb8_main.c:575 sound/isa/sb/sb8_main.c:586 sound/sparc/cs4231.c:1206 sound/sparc/cs4231.c:1217 sound/drivers/vx/vx_pcm.c:876 sound/drivers/vx/vx_pcm.c:1096 nfc_llc_ops: net/nfc/hci/llc_nop.c:85 xpc_interface: drivers/misc/sgi-xp/xp_main.c:80 intel_gvt_mpt: drivers/gpu/drm/i915/gvt/kvmgt.c:1455 i40iw_device_uk_ops: drivers/infiniband/hw/i40iw/i40iw_uk.c:936 radeon_audio_basic_funcs: drivers/gpu/drm/radeon/radeon_audio.c:128 drivers/gpu/drm/radeon/radeon_audio.c:146 drivers/gpu/drm/radeon/radeon_audio.c:140 drivers/gpu/drm/radeon/radeon_audio.c:134 vop_hw_ops: drivers/misc/mic/card/mic_device.c:312 imx_pwm_data: drivers/pwm/pwm-imx.c:261 drivers/pwm/pwm-imx.c:256 pv_time_ops: arch/x86/kernel/paravirt.c:310 smp_ops_t: arch/powerpc/platforms/pasemi/setup.c:108 arch/powerpc/platforms/chrp/smp.c:46 drm_framebuffer_funcs: drivers/gpu/drm/drm_fb_cma_helper.c:123 snd_compr_ops: sound/soc/soc-compress.c:683 sound/soc/soc-compress.c:698 sound/soc/codecs/wm5110.c:2367 drm_plane_funcs: drivers/gpu/drm/exynos/exynos_drm_plane.c:172 qed_selftest_ops: drivers/net/ethernet/qlogic/qed/qed_main.c:1568 mipi_dsi_host_ops: drivers/gpu/drm/msm/dsi/dsi_host.c:1527 i40iw_pd_ops: drivers/infiniband/hw/i40iw/i40iw_ctrl.c:4892 m48t86_ops: arch/arm/mach-orion5x/ts78xx-setup.c:98 sdhci_ops: drivers/mmc/host/sdhci-s3c.c:384 cpu_pm_ops: arch/arm/mach-omap2/omap-mpuss-lowpower.c:110 abx500_ops: drivers/mfd/ab3100-core.c:392 nfnl_ct_hook: net/netfilter/nf_conntrack_netlink.c:2392 md_cluster_operations: drivers/md/md-cluster.c:1265 intel_gvt_irq_ops: drivers/gpu/drm/i915/gvt/interrupt.c:629 isp_operations: drivers/scsi/qla2xxx/qla_os.c:2262 drivers/scsi/qla2xxx/qla_os.c:2223 drivers/scsi/qla2xxx/qla_os.c:2145 drivers/scsi/qla2xxx/qla_os.c:2106 drivers/scsi/qla2xxx/qla_os.c:2184 drivers/scsi/qla2xxx/qla_os.c:2301 drivers/scsi/qla2xxx/qla_os.c:2067 drivers/scsi/qla2xxx/qla_os.c:2028 drivers/scsi/qla2xxx/qla_os.c:1989 drivers/scsi/qla2xxx/qla_os.c:1950 mmp_overlay_ops
Re: Designated initializers, struct randomization and addressing?
On Tue, 3 Jan 2017 22:35:26 -0800 Kees Cook wrote: > For randstruct and constify, the automatic selection is done on > structures with only function pointers. (Additional structures can be > added via a compiler attribute marking.) > > See is_pure_ops_struct(): Is there anyway to use this plugin to identify pure_ops structures not already marked as const?
Re: Designated initializers, struct randomization and addressing?
On Tue, Jan 3, 2017 at 10:27 PM, Julia Lawall wrote: > > > On Tue, 3 Jan 2017, Kees Cook wrote: > >> On Tue, Dec 20, 2016 at 9:29 AM, Joe Perches wrote: >> > On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: >> >> Prepare to mark sensitive kernel structures for randomization by making >> > sure they're using designated initializers. >> > >> > About the designated initializer patches, >> > which by themselves are fine of course, >> > and the fundamental randomization plugin, >> > c guarantees that struct member ordering >> > is as specified. >> > >> > how is the code to be verified so that >> > any use of things like offsetof and any >> > address/indexing is not impacted? >> >> AIUI, offsetof() works correctly in the face of this plugin, since the >> ordering happens before the pass that handles offsetof(). Anything >> that _does not_ use offsetof(), however, needs fixing. Based on the >> work done in grsecurity, I don't see any added offsetof() uses that >> are specific to the randomization plugin. >> >> (Note that the randomization plugin is only on function pointer >> structures, where using an offsetof() should be rare to none, and on >> hand-selected structures, where missing offsetof() should be easy to >> audit.) > > What is the precise definition of "function pointer structures"? Only > function pointers? At least one function pointer? For randstruct and constify, the automatic selection is done on structures with only function pointers. (Additional structures can be added via a compiler attribute marking.) See is_pure_ops_struct(): http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c?h=kspp/gcc-plugin/randstruct -Kees -- Kees Cook Nexus Security
Re: Designated initializers, struct randomization and addressing?
On Tue, 3 Jan 2017, Kees Cook wrote: > On Tue, Dec 20, 2016 at 9:29 AM, Joe Perches wrote: > > On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: > >> Prepare to mark sensitive kernel structures for randomization by making > > sure they're using designated initializers. > > > > About the designated initializer patches, > > which by themselves are fine of course, > > and the fundamental randomization plugin, > > c guarantees that struct member ordering > > is as specified. > > > > how is the code to be verified so that > > any use of things like offsetof and any > > address/indexing is not impacted? > > AIUI, offsetof() works correctly in the face of this plugin, since the > ordering happens before the pass that handles offsetof(). Anything > that _does not_ use offsetof(), however, needs fixing. Based on the > work done in grsecurity, I don't see any added offsetof() uses that > are specific to the randomization plugin. > > (Note that the randomization plugin is only on function pointer > structures, where using an offsetof() should be rare to none, and on > hand-selected structures, where missing offsetof() should be easy to > audit.) What is the precise definition of "function pointer structures"? Only function pointers? At least one function pointer? thanks, julia
Re: Designated initializers, struct randomization and addressing?
On Tue, Jan 3, 2017 at 3:55 PM, Bruce Korb wrote: > On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook wrote: >>> how is the code to be verified so that >>> any use of things like offsetof and any >>> address/indexing is not impacted? > > As a tangential party, I am a bit curious: does the randomization > plugin result in a compact structure? I ask because I know many/most > programmers don't bother with it and so doing so ought to make the > data more compact. http://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/tree/scripts/gcc-plugins/randomize_layout_plugin.c?h=kspp/gcc-plugin/randstruct See full_shuffle() and performance_shuffle(). The latter keeps variables in the same cacheline. Neither attempt any kind of compaction. -Kees -- Kees Cook Nexus Security
Re: Designated initializers, struct randomization and addressing?
As a tangential party, I am a bit curious: does the randomization plugin result in a compact structure? I ask because I know many/most programmers don't bother with it and so doing so ought to make the data more compact. On Tue, Jan 3, 2017 at 3:47 PM, Kees Cook wrote: >> how is the code to be verified so that >> any use of things like offsetof and any >> address/indexing is not impacted?
Re: Designated initializers, struct randomization and addressing?
On Tue, Dec 20, 2016 at 9:29 AM, Joe Perches wrote: > On Fri, 2016-12-16 at 17:00 -0800, Kees Cook wrote: >> Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. > > About the designated initializer patches, > which by themselves are fine of course, > and the fundamental randomization plugin, > c guarantees that struct member ordering > is as specified. > > how is the code to be verified so that > any use of things like offsetof and any > address/indexing is not impacted? AIUI, offsetof() works correctly in the face of this plugin, since the ordering happens before the pass that handles offsetof(). Anything that _does not_ use offsetof(), however, needs fixing. Based on the work done in grsecurity, I don't see any added offsetof() uses that are specific to the randomization plugin. (Note that the randomization plugin is only on function pointer structures, where using an offsetof() should be rare to none, and on hand-selected structures, where missing offsetof() should be easy to audit.) -Kees -- Kees Cook Nexus Security