bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Ivan Zakharyaschev <imz@altlinux.org>
To: Bruno Haible <bruno@clisp.org>
Cc: bircoph@altlinux.org, bug-gnulib@gnu.org
Subject: Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address.
Date: Fri, 28 Dec 2018 17:23:09 +0300 (MSK)	[thread overview]
Message-ID: <alpine.LFD.2.20.1812280431490.6081@imap.altlinux.org> (raw)
In-Reply-To: <1787335.ZHZPG2Za76@omega>

[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]

Hi Bruno,

On Thu, 20 Dec 2018, Bruno Haible wrote:

> > +	   # E2K (elbrus) systems send SIGILL on an access to an invalid address.
> 
> This is a bug in the system. Access of an invalid address ought to produce a
> SIGSEGV or SIGBUS.
> 
> 'elbrus' is not an important OS so far, for which it would be worth adding
> workarounds in the gnulib source.
> Is it still in development? -> If so, please fix that bug.
> Or is it a museum system? -> If so, just bear with the test failure.

Of these descriptions, "system in development" is the one which suits 
Linux/E2k better. The port to E2K (MCST Elbrus general purpose hardware 
architecture) is quite mature, but not yet released publicly.

As for the SIGILL peculiarity, it has a reason in the Elbrus architecture. 
AFAIU, a different protection mechanism comes into play here. It is based 
on tagging values/memory: if an attempt is made to use a value in a way 
which contradicts its tag, then the "illegal operand" condition arises. 
Namely, a "load" instruction can expect a certain tag, and then there can 
be a mismatch between the assumptions of the code and the actual value 
and its tag.

And it's not a segmentation fault.

(This must be just a simple case of the use of tagging in this 
architecture, whereas--AFAIK--MCST has been developing some smarter 
protection modes to make use of tags to track the array bounds along with 
pointers and for other things. The smarter modes are probably not enabled 
by default in the compiler. Now, I could google up a 2018 report on such 
recent work by searching for "elbrus" "e2k" "SIGILL", in Russian.)

But wait, while writing this explanation, I seem to have come to see a way 
how the code in test-c-stack.c:

          ++*argv[argc]; /* Intentionally dereference NULL.  */

could be rewritten to cause the intended SIGSEGV and not SIGILL like now:

$ ./test-c-stack 1; echo $?
Illegal instruction
132
$ 

The tags that are seen and checked by a "load" instruction must have been 
stored before. So, if we now think about storing values to memory, we see 
that when storing a value, one is not checking the tag, but rather writing 
it initially. So (at least in the simple protection mode), there can be no 
SIGILL when writing.

And I've tested running test-c-stack with this code instead:

          *argv[argc] = 175; /* Intentionally dereference NULL.  */

and it indeed causes a SIGSEGV:

$ ./test-c-stack 1; echo $?
test-c-stack: stack overflow
77
$ 

and with libsigsegv:

$ ./test-c-stack 1; echo $?
test-c-stack: program error
Aborted
134
$ ./test-c-stack2.sh; echo $?
0
$ 

So, now I suggest a patch that replaces the reading-and-then-writing a 
value at this place with just writing a value. (A complete patch is 
attached.) This way we don't need a workaround in the test for the 
Linux/E2K platform, and the test shouldn't have got worse.

There is a possibility to follow the "first-writing" part by a 
"then-reading" part, but this doesn't seem to be essential. At least, on 
E2K and probably most other architectures it would never come to it. (But 
that way the new code would be closer to the old code in the involved 
operations, and who knows, there might be some architecture where one 
needs to read to cause a fault.)

-- 
Best regards,
Ivan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch; name=gnulib-0.1.2305-test-c-stack-e2k.patch, Size: 1397 bytes --]

From 057259bd81fbb60233df00d0a2846304088e1d47 Mon Sep 17 00:00:00 2001
From: Ivan Zakharyaschev <imz@altlinux.org>
Date: Fri, 28 Dec 2018 17:03:18 +0300
Subject: [PATCH] c-stack tests: Avoid test failure on Linux/E2K.

Reading a value without having initialized it caused a SIGILL on
Linux/E2K rather than SIGSEGV as desired.

This made test-c-stack2.sh fail on E2K. As for test-c-stack2.sh, its
intention is to test whether we can tell a stack overflow from other
cases when SIGSEGV is sent, and the way we cause a SIGSEGV in this
test is just an implementation detail. It turned out that these
implementation details need to be slightly changed for Linux/E2K.
---
 tests/test-c-stack.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/test-c-stack.c b/tests/test-c-stack.c
index 1dae74e6c..14fec8e07 100644
--- a/tests/test-c-stack.c
+++ b/tests/test-c-stack.c
@@ -63,7 +63,9 @@ main (int argc, char **argv)
       if (1 < argc)
         {
           exit_failure = 77;
-          ++*argv[argc]; /* Intentionally dereference NULL.  */
+          *argv[argc] = 175; /* Intentionally dereference NULL.  Writing an
+                                arbitrary value, because reading without having
+                                initialized it causes a SIGILL on Linux/E2K.  */
         }
       return recurse (0);
     }
-- 
2.19.2


  reply	other threads:[~2018-12-28 14:34 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-15 12:50 [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address Ivan Zakharyaschev
2018-12-20  2:24 ` Bruno Haible
2018-12-28 14:23   ` Ivan Zakharyaschev [this message]
2018-12-29 11:17     ` Bruno Haible
2018-12-29 11:31       ` Andrey Savchenko
2018-12-29 14:03         ` Bruno Haible
2018-12-29 14:31         ` Dmitry V. Levin
2018-12-29 14:54       ` Bruno Haible
2018-12-29 15:03       ` Ivan Zakharyaschev
2018-12-29 16:30         ` Dmitry V. Levin
2018-12-29 20:13         ` Ivan Zakharyaschev
2018-12-30  4:49           ` Bruno Haible
2018-12-29 13:54     ` Dmitry V. Levin
2018-12-29 15:15       ` Ivan Zakharyaschev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.20.1812280431490.6081@imap.altlinux.org \
    --to=imz@altlinux.org \
    --cc=bircoph@altlinux.org \
    --cc=bruno@clisp.org \
    --cc=bug-gnulib@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).