the various libc implementations don't
> agree, then the actual kernel limit changed again while I was looking at it.
>
>>Linus
>
> Should I just go back to hardwiring in 131072? It's no _less_ arbitrary
> than 10 megs, and it sounds like getting it _right_ is unachievable.
>
> Thanks,
>
> Rob
>
>
> ___
> Toybox mailing list
> toy...@lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
utimensat always returns success if both times are UTIME_OMIT, even if
the file doesn't exist or dirfd is invalid.
$ cat x.c
#include
#include
int main(int argc, char* argv) {
struct timespec times[2] = { { 0, UTIME_OMIT }, { 0, UTIME_OMIT } };
struct stat sb;
stat("does-not-exist", &sb); /
The ELF specification says that d_val is an Elf32_Word, not an Elf32_Sword.
This also matches glibc, and fixes bionic (Android's C library, which uses
the uapi header).
Patch is against -rc ToT.
Signed-off-by: Elliott Hughes
---
include/uapi/linux/elf.h | 2 +-
1 file changed, 1 insertion(+), 1
The ELF specification says that d_val is an Elf32_Word, not an Elf32_Sword.
This also matches glibc, and fixes bionic (Android's C library, which uses
the uapi header).
Patch is against -rc ToT.
Signed-off-by: Elliott Hughes
---
include/uapi/linux/elf.h | 2 +-
1 file changed, 1 insertion(+), 1
On Thu, May 23, 2019 at 7:45 AM Catalin Marinas wrote:
>
> On Wed, May 22, 2019 at 01:47:36PM -0700, Kees Cook wrote:
> > On Wed, May 22, 2019 at 05:35:27PM +0100, Catalin Marinas wrote:
> > > The two hard requirements I have for supporting any new hardware feature
> > > in Linux are (1) a single
se really shouldn't happen, but it was the case we
> considered (and rejected) for suid binaries.
>
> So that's the real reason the kernel behavior changed: we had a
> security issue with the "we allow basically unlimited stack growth"
> where a huge argv/envp could be used to grow the stack into some other
> segment.
>
> Realistically, it was only a security issue with suid binaries, but as
> mentioned in this thread, the problem is that we do the argument
> copying even before we've decided whether the execve is going to be a
> suid execve.
>
> So then - exactly so that we do *not* have that nasty case of "execve
> succeeds, but we kill the process immediately if it turns into a
> potential security issue", we do that "limit the stack growth for
> everybody".
>
> Linus
--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
6 matches
Mail list logo