27;s mostly arbitrary. :(
> (and thank you for your explanations)
Sure thing! Thanks for your (and everyone's) help clarifying this whole
area. :)
-Kees
--
Kees Cook
the following question: In the
> bug you refer to above, an unsigned variable was used
> for something that is not meant for modulo arithmetic.
> Is this done in the kernel to save space? I.e. because
> 127 would not be enough as maximum but going to i16 takes
> to much space? or is this for compatibility with some
> on-the-wire protocol?
I don't know the original rationale -- I expect the author wanted an
unsigned variable but didn't expect to ever encounter > 255 entries.
These kinds of expectations aren't uncommon in the kernel, and sometimes
past expectations get violated when refactoring, etc. Basically I can't
trust the sanity of the codebase, so I have to depend on the compiler to
provide the runtime coverage to avoid these kinds of security flaws.
> Would an attribute for variables help that tells the
> compiler that if stores to the variable wrap around
> then this is not intended and this is an error?
>
> u8 x [[nowrap]];
>
> x = 256; // can be diagnosed ?
I would need the reverse: I want to assume all math to not wrap,
excepting a handful that are designed to.
-fsanitize=nowrap
u8 modulo [[wrapping]];
u8 counter;
modulo = 256; // no diagnose
counter = 256; // diagnose
--
Kees Cook
On Thu, May 11, 2023 at 09:43:49PM +, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>
> > Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> > question is: what's needed to support the idea of a zero-sized object?
>
On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>
> > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > On 5/11/23 18:07, Alejandro Colomar wrote:
> > > [...]
> > > >
overage over trailing arrays. All of this means that
we're converting a lot of code that is happily using dynamically sized
arrays in unions, etc.
[1] https://people.kernel.org/kees/bounded-flexible-arrays-in-c
--
Kees Cook
c-plugins:
> gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK) \
> += -fplugin-arg-stackleak_plugin-verbose
>
> Signed-off-by: Alexander Popov
Applied to for-next/gcc-plugins.
--
Kees Cook
On Wed, Jun 24, 2020 at 03:33:27PM +0300, Alexander Popov wrote:
> Don't use gcc plugins for building arch/arm/vdso/vgettimeofday.c to
> avoid unneeded instrumentation.
>
> Signed-off-by: Alexander Popov
Applied to for-next/gcc-plugins.
--
Kees Cook
On Wed, Jun 24, 2020 at 03:33:26PM +0300, Alexander Popov wrote:
> There is no need to try instrumenting functions in kernel/stackleak.c.
> Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
> is disabled.
>
> Signed-off-by: Alexander Popov
> Acked-by:
On Wed, Jun 24, 2020 at 03:33:28PM +0300, Alexander Popov wrote:
> Don't use gcc plugins for building arch/arm64/kernel/vdso/vgettimeofday.c
> to avoid unneeded instrumentation.
>
> Signed-off-by: Alexander Popov
It looks like Will has taken this already, but:
Acked-by: Kee
ich is used for debugging the structleak plugin.
>
> This debugging feature clutters the kernel build output, I don't think that
> many
> people will use it. So IMO creating a separate argument for make is not really
> needed.
Yup, agreed. The precedent for plugin verbosity is via CONFIGs. They're
not really general purpose enough to justify a "make" argument.
--
Kees Cook
On Wed, Jun 10, 2020 at 06:52:10PM +0300, Alexander Popov wrote:
> On 09.06.2020 21:47, Kees Cook wrote:
> > On Thu, Jun 04, 2020 at 04:49:55PM +0300, Alexander Popov wrote:
> >> Add 'verbose' plugin parameter for stackleak gcc plugin.
> >> It can be used f
On Wed, Jun 10, 2020 at 06:47:14PM +0300, Alexander Popov wrote:
> On 09.06.2020 21:46, Kees Cook wrote:
> The inline asm statement that is used for instrumentation is arch-specific.
> Trying to add
> asm volatile("call stackleak_track_stack")
> in gcc plugin o
GCC_PLUGINS architectures with vDSOs (which appears to be all of
them except um).
--
Kees Cook
should likely be disabled too.
sancov_plugin.c
This should be tracking the KCOV directly (see
scripts/Makefile.kcov), which is already disabled here.
structleak_plugin.c
This should be fine in the vDSO, but there's not security
boundary here, so it wouldn't be important to KEEP it enabled.
--
Kees Cook
On Thu, Jun 04, 2020 at 04:49:56PM +0300, Alexander Popov wrote:
> There is no need to try instrumenting functions in kernel/stackleak.c.
> Otherwise that can cause issues if the cleanup pass of stackleak gcc plugin
> is disabled.
>
> Signed-off-by: Alexander Popov
Acke
ately.
Why does the architecture need to be tested? (i.e. when this flag
becomes supported o other architectures, why must it still be x86-only?)
--
Kees Cook
c-plugins:
> gcc-plugin-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK) \
> += -fplugin-arg-stackleak_plugin-verbose
>
> Signed-off-by: Alexander Popov
Acked-by: Kees Cook
--
Kees Cook
to be strictly tied together.
> Another aspect: CONFIG_STACKLEAK_METRICS can be used for guessing kernel stack
> offset, which is bad. It should be disabled if random_kstack_offset is on.
Agreed.
--
Kees Cook
On Thu, Jun 04, 2020 at 04:49:52PM +0300, Alexander Popov wrote:
> In this patch series I collected various improvements of the stackleak
> gcc plugin.
Great; thank you! I'll take a closer look at this shortly!
--
Kees Cook
function prologues and epilogues are generated, and the
> +* machine-dependent code transformations are not done.
> */
> - PASS_INFO(stackleak_cleanup, "reload", 1, PASS_POS_INSERT_AFTER);
> + PASS_INFO(stackleak_cleanup, "*free_cfg", 1, PASS_POS_INSERT_BEFORE);
>
> if (!plugin_default_version_check(version, &gcc_version)) {
> error(G_("incompatible gcc/plugin versions"));
> --
> 2.7.4
>
--
Kees Cook
20 matches
Mail list logo
