Re: Probe emission in fstack-clash-protection

[Eric Botcazou via Gcc]

> That may ultimately be better for -fstack-check to make it more robust,
> but it still wouldn't be a viable alternative for stack clash protection
> for the reasons laid out in that blog post.

Well, -fstack-check does that when it's possible, e.g. on Windows, but it's 
not on x86[_64]/Linux where you *cannot* probe below the stack pointer.

-- 
Eric Botcazou

Re: Probe emission in fstack-clash-protection

[Florian Weimer via Gcc]

* Varun Kumar E. via Gcc:

> Hello,
>
> https://godbolt.org/z/P3M8s8jqh
> The above case shows that gcc first decreases the stack pointer and then
> probes.
>
> As mentioned by Jeff Law (reference
> )
> under "More issues with -fstack-check". If an asynchronous signal is
> received between the decrement of stack pointer and probing of the pages.
> *"In that case, the stack pointer could be pointing beyond the guard into
> the heap. The signal arrives and the kernel transfers control to the
> registered signal handler. That signal handler is then running while its
> stack is pointing into the heap. Thus, the attacker has clashed the stack
> and heap, and there's a reasonable chance they can gain control over the
> program" *
>
> So, Shouldn't we first probe and if successful only then update the stack
> pointer? Or Maybe I have understood it incorrectly.

Let me rephrase a bit.  The caller has asserted that (%rsp) is valid
upon entry to the function because that's where the return address is
stored.  That means that (%rsp - 4096) is still in the guard page, so
the subsequent probe works.  But the kernel fault handler will not write
to that location because it has to protect the return address and the
red zone, so the first location used is (%rsp - 4096 - 8 - 128) or
thereabouts.

Jeff, this looks like a real bug to me.  It doesn't affect the main
thread on GNU/Linux because the kernel uses more than one page for the
guard area.  However, glibc uses exactly one page.  We could change that
to two pages on x86-64 at least without ill effects, I believe.  Or fix
GCC's probing to account for the red zone.

Thanks,
Florian

[RISC-V] [SIG-toolchain] Meeting will be canceled (May 4, 2023)

[jiawei]

Hi all,




Tomorrow's meeting will be canceled, since there were few new topics to discuss.




The next RISC-V GNU Toolchain meeting is collecting topics:

https://docs.google.com/document/d/1JSs-BSlPJ3QYbAb-Add1TlbYx0nOT1ur3jcsITIJ01U/edit?usp=sharing

Please add what want to discuss in the next meeting.




GCC 13 released in April 26,you can check changes in the release notes:


https://gcc.gnu.org/gcc-13/changes.html




Best Regards,

Jiawei

gcc-10-20230503 is now available

[GCC Administrator via Gcc]

Snapshot gcc-10-20230503 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/10-20230503/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-10 revision b357af31b8d1e93f0f70133e25d3ad4045f7a32b

You'll find:

 gcc-10-20230503.tar.xz   Complete GCC

  SHA256=abfd0ffa49c1f16842933efb5141d633173d99d8ef7c7f195b33e324f4fc26ed
  SHA1=5ff2911725ea92d468186687b4893d713eec3a6b

Diffs from 10-20230426 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.