Bug#537622: tcc FTB mksh with bounds checking
Thomas Preudhomme dixit: > That's special casing environ. The same problem happen for sys_siglist or > other > variable. Basically anything not compiled with tcc will be a problem as there Ah, right. And since we use sys_siglist[] and (if exists) sys_signame[] we’ll clash there too… bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537622: tcc FTB mksh with bounds checking
Le 2014-04-01 00:43, Thorsten Glaser a écrit : Ah okay. The problem is that “environ” is more portable than what I got to know as “envp” and you called “arge”, so the shell uses that instead. Ah yeah envp. I totally forgot the usual name as I almost never write a program from scratch and when I do I don't need it. A possible hack: if the program references a global symbol environ, insert pseudo-code at the beginning of main that does “environ = arge;”. That's special casing environ. The same problem happen for sys_siglist or other variable. Basically anything not compiled with tcc will be a problem as there will be no bound region created for it. argv and envp are just both more common and a bit special as they don't come from a library but the calling process. OK. Sounds like… business as usual. I know that ☻ :) Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537622: tcc FTB mksh with bounds checking
Thomas Preud'homme dixit: >> >failed on the use of environ because the bound checking code cannot know >> >the size of the valid area for environ and thus thinks an unsafe access is >> >being >> Hm. Well, “environ” is just a pointer to some (structured but not >> easily bound) memory are. There *could* be code to scan for the >> end, but that’d not perform. >That's what I added in tcc for argv and the arge (third parameter of main). Ah okay. The problem is that “environ” is more portable than what I got to know as “envp” and you called “arge”, so the shell uses that instead. >in the general case, tcc cannot know when considering an externally defined >symbol if it's an array ended with a NULL value. We need a more generic A possible hack: if the program references a global symbol environ, insert pseudo-code at the beginning of main that does “environ = arge;”. >> Thanks, much welcome! Are you also upstream? > >Yep. When I took over the maintainance of tcc I soon discovered that all of >the bugs that were reported were upstream bug and that nobody would work on >them if I didn't. So I started tackling just the bugs reported within Debian >and eventually I became upstream. :) OK. Sounds like… business as usual. I know that ☻ Thanks, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537622: tcc FTB mksh with bounds checking
Le dimanche 30 mars 2014, 18:19:32 Thorsten Glaser a écrit : > Oh, nice. I’ve found logs of bugs in, for example, GCC with it too, > but They never bothered to fix them, they just deprecated the code. We'll try to avoid that but it seems quite clear that that will imply doing less checks to cover currently problematic cases. > Yes, surprisingly. Signals, for example on Linux/amd64, go from 1 to 64, > with valid kill() arguments and siglist entries ranging from 0 to 64, > where 0 is just never used. They shift the 1‥64 into 0‥63 for the signal > mask in order to not waste any. Ok, so a bug in tcc then. > > If they are NULL it doesn’t matter because mksh does "Signal %d" then. > It basically doesn’t dereference it. But it’s important that NSIG has > them, so a user can send those signals (they are real-time signals, > but still valid). Certainly, I was not implying there was a bug in mksh in the null case, just that I could see it confusing bound checking code in some way. > > >failed on the use of environ because the bound checking code cannot know > >the size of the valid area for environ and thus thinks an unsafe access is > >being > Hm. Well, “environ” is just a pointer to some (structured but not > easily bound) memory are. There *could* be code to scan for the > end, but that’d not perform. That's what I added in tcc for argv and the arge (third parameter of main). Look for the end of the array and register a bound region. But it doesn't work in the general case, tcc cannot know when considering an externally defined symbol if it's an array ended with a NULL value. We need a more generic solution. > > OK. If there is anything I should change in mksh (especially if it > could be a bug rather than a compiler workaround), feel free to say > so. (On the other hand, other compiler authors _did_ recommend to > just disable the bounds checking flag because their compilers’ code > for that didn’t manage to work, either.) We'll see but I'm afraid it'll have to wait for the release after the one coming soon. > > Thanks, much welcome! Are you also upstream? Yep. When I took over the maintainance of tcc I soon discovered that all of the bugs that were reported were upstream bug and that nobody would work on them if I didn't. So I started tackling just the bugs reported within Debian and eventually I became upstream. :) Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537622: tcc FTB mksh with bounds checking
Thomas Preud'homme dixit: >I took a look at this bug recently. Thanks to this, two bugs have been fixed >in Oh, nice. I’ve found logs of bugs in, for example, GCC with it too, but They never bothered to fix them, they just deprecated the code. >I managed to go a bit further by changing the condition on NSIG from <= NSIG >to < NSIG in inittraps in histrap.c Are you sure it should be <=NSIG? Yes, surprisingly. Signals, for example on Linux/amd64, go from 1 to 64, with valid kill() arguments and siglist entries ranging from 0 to 64, where 0 is just never used. They shift the 1‥64 into 0‥63 for the signal mask in order to not waste any. >I could go even further by changing NSIG to 32 when I noticed that the entries >from 32 to 64 are null (I thought it could confuse tcc in some way). It then If they are NULL it doesn’t matter because mksh does "Signal %d" then. It basically doesn’t dereference it. But it’s important that NSIG has them, so a user can send those signals (they are real-time signals, but still valid). >failed on the use of environ because the bound checking code cannot know the >size of the valid area for environ and thus thinks an unsafe access is being Hm. Well, “environ” is just a pointer to some (structured but not easily bound) memory are. There *could* be code to scan for the end, but that’d not perform. >The problem in histtrap seems to be the same. When computing the address >of histtraps[i] at some point the bound checking code returns -2 (access to >unsafe zone) which once multiplied by i * sizeof(void *) goes in the end of >address space and causes a crash. I'll think how to solve this. OK. If there is anything I should change in mksh (especially if it could be a bug rather than a compiler workaround), feel free to say so. (On the other hand, other compiler authors _did_ recommend to just disable the bounds checking flag because their compilers’ code for that didn’t manage to work, either.) >Anyway, I just wanted to tell you that we are trying to fix this and we didn't >forget that bug. Thanks, much welcome! Are you also upstream? bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#537622: tcc FTB mksh with bounds checking
Le mardi 3 janvier 2012 17:03:29, vous avez écrit : > > I’m omitting -b when building mksh with tcc now, and it works > and passes its testsuite fully, on i386. Just FYI. I took a look at this bug recently. Thanks to this, two bugs have been fixed in tcc. Sadly it was regression both in tcc and due to change in the environment. I managed to go a bit further by changing the condition on NSIG from <= NSIG to < NSIG in inittraps in histrap.c Are you sure it should be <=NSIG? I could go even further by changing NSIG to 32 when I noticed that the entries from 32 to 64 are null (I thought it could confuse tcc in some way). It then failed on the use of environ because the bound checking code cannot know the size of the valid area for environ and thus thinks an unsafe access is being done. The problem in histtrap seems to be the same. When computing the address of histtraps[i] at some point the bound checking code returns -2 (access to unsafe zone) which once multiplied by i * sizeof(void *) goes in the end of address space and causes a crash. I'll think how to solve this. Anyway, I just wanted to tell you that we are trying to fix this and we didn't forget that bug. Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Bug#537622: tcc FTB mksh with bounds checking
found 537622 tcc/0.9.25-11 severity 537622 minor thanks I’m omitting -b when building mksh with tcc now, and it works and passes its testsuite fully, on i386. Just FYI. bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
