Re: Designated initializers, struct randomization and addressing?

2017-01-04 Thread Kees Cook 
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?

2017-01-04 Thread Kees Cook 
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?

2017-01-04 Thread Julia Lawall 


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

Re: Designated initializers, struct randomization and addressing?

2017-01-04 Thread Julia Lawall 


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

Re: Designated initializers, struct randomization and addressing?

2017-01-04 Thread Stephen Hemminger 
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?

2017-01-04 Thread Stephen Hemminger 
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?

2017-01-03 Thread Kees Cook 
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?

2017-01-03 Thread Kees Cook 
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?

2017-01-03 Thread Julia Lawall 


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?

2017-01-03 Thread Julia Lawall 


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?

2017-01-03 Thread Kees Cook 
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?

2017-01-03 Thread Kees Cook 
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?

2017-01-03 Thread Bruce Korb 
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?

2017-01-03 Thread Bruce Korb 
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?

2017-01-03 Thread Kees Cook 
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

Re: Designated initializers, struct randomization and addressing?

2017-01-03 Thread Kees Cook 
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