Getting the way a SIGSEGV append when catching a SIGSEGV from within
Hello, There’s three way to perform an invalid memory access : The attempt to execute/jump at an invalid address. The attempt to read at an invalid address. The attempt to write at an invalid address. Determining the execute case with rt_sigaction is easy : the last value of eip match the value of the address which caused the segfault. But how to know if the SIGSEGV occurred by a read or by a write attempt ? In the same time shouldn’t that information belong in the mmu ?
Re: Getting the way a SIGSEGV append when catching a SIGSEGV from within
Le 2017-03-27 17:30, Richard Weinberger a écrit : On Mon, Mar 27, 2017 at 4:45 PM, none wrote: Hello, There’s three way to perform an invalid memory access : The attempt to execute/jump at an invalid address. The attempt to read at an invalid address. The attempt to write at an invalid address. Determining the execute case with rt_sigaction is easy : the last value of eip match the value of the address which caused the segfault. But how to know if the SIGSEGV occurred by a read or by a write attempt ? In the same time shouldn’t that information belong in the mmu ? Did you look at the machine specific context of SIGSEGV? It will give you access to the error code and the trap number. Sorry but so, in the case of x86_64, which is the struct member I need to look at ?
when to size_t for representing length instead of int ?
Hello, I wanted to known the rules in coding guidelines concerning the use of size_t. It seems the signed int type is used most of the time for representing string sizes, including in some parts written by Linus in /lib. They’re can buffer overflows attack if ssize_t if larger than sizeof(int) (though I agree this isn’t the only way, but at least it´s less error prone). So is it guaranteed for all current and future cpu architectures the Linux kernel support that ssize_t will always be equal to sizeof(int) ? regards,
Re: when to size_t for representing length instead of int ?
Le 2016-10-14 01:37, Al Viro a écrit : On Fri, Oct 14, 2016 at 12:12:43AM +0200, none wrote: Hello, I wanted to known the rules in coding guidelines concerning the use of size_t. It seems the signed int type is used most of the time for representing string sizes, including in some parts written by Linus in /lib. They’re can buffer overflows attack if ssize_t if larger than sizeof(int) (though I agree this isn’t the only way, but at least it´s less error prone). Huh? size_t is the type of sizoef result; ssize_t is its signed counterpart. With large strings, you can make buffer overflows by turning ints into negative values (this lead to cwe 195). However, they just crash the process and thus can’t be used for remote code execution. So as long as the truncation can’t lead to positive values there’s nothing to fear (which mean using in instead of size_t is acceptable if the machine isn’t big_endian). So is it guaranteed for all current and future cpu architectures the Linux kernel support that ssize_t will always be equal to sizeof(int) ? Of course it isn't. Not true on any 64bit architecture we support... No this is guaranteed, at least for amd64 because of -mcmodel=kernel What attacks are, in your opinion, enabled by that fact? I'm sure that libc (and C standard) folks would be very interested, considering that e.g. strlen() is declared as function that takes a pointer to const char and returns size_t... Plenty attacks which leads to plenty types of cwe (192 or 190)… Basically you feed the software with a string which can fit in size_t but not in an unsigned int. I call this “size_t to positive int truncation” attacks (too bad that there’s no specific cwe for it). This rely on the following abi characteristics : — being able to get a variable representing the length of a string (which uses size_t because of malloc) to a positive value of a variable which use the “int” type — being on little endian machine makes the remote execution easier (because bettes every odd values which count the number of times of sizeof(int) the buffer overflow will be positive). But the best illustration of this is probably myself being listed in the top ten of https://bounty.github.com because of that kind of bug in git :) iii
Re: [RFC] Linux Kernel Subversion Howto
On Fri, February 11, 2005 11:18 am, Larry McVoy said: The mails have started flowing in saying "I don't agree with Alexandre and please don't pull the plug" so a point of clarification. We have no intention of shutting down the BK free product. We are aware that there are 10's of thousands of developers in the open source world who do not agree with Alexandre's narrow view of things. You're fine, we're not taking BK away. I only trying to get Alexandre to see that his definition of "help" is somewhat narrow-minded. Then why don't you stop threatening to take it away every time someone points out to you that your "help" for free software isn't ideal? Just can't help yourself? Your cheap shot at Alexandre doesn't change the fact that you've shown yet again why people who believe in free software should work to replace BK. Cheers, Hank _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
