Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Wed, Oct 29, 2014 at 12:05 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: On Wed, Oct 29, 2014 at 7:31 AM, nick xerofo...@gmail.com wrote: Greg, That's fine, I was wondering how long Greg KH takes to get around to picking this up as he is very busy with other kernel work. it might take a long long time. i think he is very busy now. I have not seen his replies to patches in the kernel list for atleast last 3 weeks. [snip] ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Nah. Greg KH is a robot. I'm firmly convinced that man doesn't sleep. If I didn't know better, I'd think he's a Cylon. On a serious note; realistically, a two week window isn't unheard of for getting your patches to mainline. So long as you're not trying to sneak in right as the merge window is closing, you'll make the next release. In fact, if you submit early enough, you can almost forget that you have a patch in a kernel when it's released 2 months later. Nothing like reading the release notes and finding your own patches that you've forgotten about over your morning coffee. :) -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging: rtl8723au: Fix brace coding style issues reported by checkpatch
On Wed, Oct 29, 2014 at 1:48 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: On Wed, Oct 29, 2014 at 11:38 AM, Scott Lovenberg scott.lovenb...@gmail.com wrote: On Wed, Oct 29, 2014 at 12:05 AM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: On Wed, Oct 29, 2014 at 7:31 AM, nick xerofo...@gmail.com wrote: Greg, That's fine, I was wondering how long Greg KH takes to get around to picking this up as he is very busy with other kernel work. it might take a long long time. i think he is very busy now. I have not seen his replies to patches in the kernel list for atleast last 3 weeks. [snip] ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Nah. Greg KH is a robot. I'm firmly convinced that man doesn't sleep. If I didn't know better, I'd think he's a Cylon. well said. On a serious note; realistically, a two week window isn't unheard of for getting your patches to mainline. So long as you're not trying to mine is three weeks going on now. somehow i have managed to send my patches just at the beginning of the merge window. :( yesterday i saw Greg K-H releasing the stable patches , so i guess now he will be seeing the pending staging patches. It also depends on how many hops you are to the maintainer and how heavy their workload is. Sometimes you can directly submit to them, other times your patches will be passed through three trees before they see mainline. It all depends on what you're working on and who's in your circle. -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Patch submission issue
On Tue, Jun 10, 2014 at 10:29 PM, Greg KH g...@kroah.com wrote: On Wed, Jun 11, 2014 at 07:23:08AM +0530, Raghavendra wrote: Hello, I am new to the kernel development community and I started off by fixing small coding style errors in the drivers/staging directory. I've created a patch for the same and sent it to the maintainer. The maintainer replied to me something like this : Please don't do multiple things in the same patch, a single patch should only do 1 thing. So break this up into multiple patches. And my patch looks something like this : From 7effd3d61c6ce08cd44df0a5ba3d1e9ac9ab5a98 Mon Sep 17 00:00:00 2001 From: Raghavendra ar...@cdac.in Date: Tue, 10 Jun 2014 22:04:52 +0530 Subject: [PATCH] Staging: rtl8192e: dot11d: Fixed coding style issues Replaced 'printk' with 'netdev_info' and 'netdev_err' wherever necessary. Also fixed the coding issue cooresponding to line gap after the declarations. You said also, so that means you did 2 different things. Split this up into two different patches, one doing the first thing, and the second the second thing. See the documentation for how to do multiple patches in an email series. To follow up on what Greg KH said, once you learn the git-send-email workflow, you'll love it. That being said, I still do a dry run and only send to myself first (I have a gmail filter for this that tags my own stuff) for larger sets of patches. Make everyone's life easier by testing your workflow once or twice before sending multi-patch sets. It's embarrassing to have to send a series of patches three times because you set the incorrect flag or forgot to add a signed-off-by when you git-format-patch (and then forget to add it when using git-send-email). Please learn from my mistakes, I know I haven't. :) -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] net: ethernet: clean out braces / old code (found via checkpatch)
On Wed, Oct 3, 2012 at 5:13 AM, Matthew Walster matt...@walster.org wrote: On 2 October 2012 17:16, Scott Lovenberg scott.lovenb...@gmail.com wrote: Looks good to me. Maintainer didn't think so :( On 2 October 2012 19:46, David Miller da...@davemloft.net wrote: That comment and that unconditional if() are documentation. Don't be an automaton and blindly make changes based upon checkpatch.pl output. Perhaps I'll just clean up some of drivers/staging while I learn the process before I dive in to net again. Matthew Walster Sorry, man. I'm not going to mix it up with Dave Miller, but really if he wanted that to stay in there a comment suggesting so would have been nice. -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] net: ethernet: clean out braces / old code (found via checkpatch)
On Tue, Oct 2, 2012 at 6:56 AM, matt...@walster.org wrote:
From: Matthew Walster matt...@walster.org
Remove an old commented out piece of code.
Remove an if(true) statement.
Remove a set of braces that weren't strictly necessary.
All found by running checkpatch.pl against the code.
Signed-off-by: Matthew Walster matt...@walster.org
---
net/ethernet/eth.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 4efad53..a9f8531 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -178,11 +178,8 @@ __be16 eth_type_trans(struct sk_buff *skb, struct
net_device *dev)
* seems to set IFF_PROMISC.
*/
- else if (1 /*dev-flagsIFF_PROMISC */ ) {
- if (unlikely(!ether_addr_equal_64bits(eth-h_dest,
- dev-dev_addr)))
- skb-pkt_type = PACKET_OTHERHOST;
- }
+ else if (unlikely(!ether_addr_equal_64bits(eth-h_dest,
dev-dev_addr)))
+ skb-pkt_type = PACKET_OTHERHOST;
/*
* Some variants of DSA tagging don't have an ethertype field
--
1.7.10.4
Looks good to me.
--
Peace and Blessings,
-Scott.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: starting to patch kernel
On Wed, Sep 26, 2012 at 4:21 PM, Constantine Shulyupin co...@makelinux.comwrote: Hi I am experienced embedded Linux driver developer. I have some spare time which I want to contribute to mainstream Linux kernel. Unfortunately http://kernelnewbies.org/KernelJanitors/Todo is very old. Can you please suggest small tasks good for start? It can be code clean up, API updates. Thank you -- Constantine Shulyupin http://www.MakeLinux.com/ Embedded Linux Systems, Device Drivers, TI DaVinci ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies You might want to ask Jeff Layton or Steve French (both CCed) about working on some code in the NFS tree. There's always a lot of stuff going on over there. The mailing list is somewhat active, too (at least for a file system mailing list). I don't know if that's anything you'd be interested in, but I like to lurk there among other places. -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does Linux process exist information leakage?
On Tue, Jan 17, 2012 at 20:53, Fredrick fjohn...@zoho.com wrote: When you malloc a memory or mmap a MAP_ANON memory, it is virtually allocated. When you read or write to it, the process takes a page fault. The page fault handler zeroes those memory and hands it to the process. So I think there is no leak. -Fredrick Thanks for clearing that up. I learned something today. :) -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does Linux process exist information leakage?
On Mon, Jan 16, 2012 at 18:45, Jonathan Neuschäfer j.neuschae...@gmx.netwrote:
On Mon, Jan 16, 2012 at 01:19:22PM -0500, Scott Lovenberg wrote:
Let me walk you guys through how this bug could be exploited.
The file that you want to access is blocked from you by file system
permissions. The root user (uid==0) can access this file (that contains
credentials) and read it into memory that it has malloc()'ed. After the
process running as root is done, it free()'s the memory without zeroing
it
out. Now you (you clever hacker) spawn a process that requests memory in
large hunks. It then searches for the string password= in that memory.
Since the memory was free()'ed back to the pool without being changed,
it
still contains the original information that was in the file that you
cannot read. Does this make sense, or should I go into t a bit more
detail?
But can you actually get this dirty memory on Linux?
I know two sources of memory that are used by malloc. One is brk(), the
other is mmapped pages of /dev/zero. With /dev/zero it's obvious that
you get empty pages (all-zero); with brk I wasn't sure so I wrote the
test program below and ran it. I didn't find any dirty (non-zero) memory.
Thanks,
Jonathan Neuschäfer
--
#include unistd.h
#include stdio.h
#define BLOCKSZ (1024 * 1024) /* one Mibi */
int main(void)
{
int maxmb = 1024;
unsigned i;
void *BRK;
BRK = sbrk(0);
for (i = 0; i maxmb; i++) {
void *block = sbrk(BLOCKSZ);
unsigned j, *p;
if (block == (void *) -1) {
printf(sbrk failed after %u blocks (%u bytes)\n,
i, i * BLOCKSZ);
break;
}
for (p = block, j = BLOCKSZ/sizeof(unsigned int); j--; p++)
if (*p)
printf(found data at BRK+%p: %u\n, ((void
*)p) - BRK, *p);
}
return 0;
}
Thanks for posting this. I'm embarrassed that I never even bothered to
check if dirty memory was given back. I guess I just assumed. You know
what they say about assumptions... Anyways, I think this is a great
discussion. :)
--
Peace and Blessings,
-Scott.
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does Linux process exist information leakage?
On Thu, Jan 12, 2012 at 12:00, Jonathan Neuschäfer j.neuschae...@gmx.netwrote: On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote: Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run. I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS. Could you please clarify how this churning through memory would work? Of course someone could find another security bug and access heap space, but that requires said other bug. Debuggers are also irrelevant to this, because you need certain parmissions to run a program through a debugger, and if you do that, you might also set a breakpoint in the function and catch the credentials when it's run. Swap disk are a real issue under some circumstances, though. A page containing sensitive data may be swapped out and not be over- written before an attacker can boot from an external medium (CD etc.) and peek through the swap disk. If you don't suspend (which means writing all pages to persistent storage), mlock() would be the solution here (CMIIW). (Which doesn't mean zeroing isn't also a good idea) Of course, people should also encrypt their disks on this kind of server. Thanks, Jonathan Neuschäfer Sorry for taking so long to reply. Let me walk you guys through how this bug could be exploited. The file that you want to access is blocked from you by file system permissions. The root user (uid==0) can access this file (that contains credentials) and read it into memory that it has malloc()'ed. After the process running as root is done, it free()'s the memory without zeroing it out. Now you (you clever hacker) spawn a process that requests memory in large hunks. It then searches for the string password= in that memory. Since the memory was free()'ed back to the pool without being changed, it still contains the original information that was in the file that you cannot read. Does this make sense, or should I go into t a bit more detail? -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does Linux process exist information leakage?
On Mon, Jan 16, 2012 at 13:45, Greg Freemyer greg.freem...@gmail.comwrote: On Thu, Jan 12, 2012 at 12:00 PM, Jonathan Neuschäfer j.neuschae...@gmx.net wrote: On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote: Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run. I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS. Could you please clarify how this churning through memory would work? Of course someone could find another security bug and access heap space, but that requires said other bug. Debuggers are also irrelevant to this, because you need certain parmissions to run a program through a debugger, and if you do that, you might also set a breakpoint in the function and catch the credentials when it's run. Swap disk are a real issue under some circumstances, though. A page containing sensitive data may be swapped out and not be over- written before an attacker can boot from an external medium (CD etc.) and peek through the swap disk. Boot CDs mean physical access. If the bad guy has physical access, all is lost. === specifically If you want to defend against reboots to a boot CD, then all of memory is potential leak. http://citp.princeton.edu/research/memory/ My personal favorite is when they actually move the RAM chips from one PC to another to get the data out of it. After removing power, they immediately spray freon (or something similarly cold) on the RAM chips to stabilize them, then move them to another PC and recover the content. I can't get the video to work right now, but here's a walk-thru with photos. I quote: === We stored data in these memory modules, then cooled them, removed them from the computer, and placed them in a container of liquid nitrogen for an hour. After returning them to the computer, we found practically no information had been lost. (Using liquid nitrogen would be overkill for most attacks, since cheap, widely-available duster spray would adequately cool the chips.) === Greg I should clarify (because someone asked), the memory that I was talking about wouldn't be allocatable until after the process that read it and freed it exited. -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Does Linux process exist information leakage?
On Wed, Jan 11, 2012 at 11:45, Dave Hylands dhyla...@gmail.com wrote: Hi, On Wed, Jan 11, 2012 at 4:53 AM, 夏业添 summer...@gmail.com wrote: Hi, My tutor asked me to test whether one process leaves information in memory after it is dead. I tried to search some article about such thing on the Internet but there seems to be no one discuss about it. And after that, I tried to write some program in the User Mode to test it, using fork() to create lots of processes and filling char 'a' into a 102400 bytes char array in each process. Then I used malloc() to get some memory to seek char 'a' in a new one process or many new processes, but failed. All memory I malloced was full of zero. Yeah - so if it were possible for one process to get information about another process like that you would have a security leak. As the man page of malloc said:The memory is not initialized, I believe that the memory which was got by malloc() could be used by other process, and therefor information leakage exists. But how can I test it? Or where can I get related information? All pages allocated from the OS will be initially zero'd, however, once your process owns the page, if you filled it with Z's and then freed it and reallocated you might very weill get your Z's back instead of 0's. You'll never get data from another process though. Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run. I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS. http://git.samba.org/?p=cifs-utils.git;a=commitdiff;h=6c917ebf360b3dbbc4c7ad9af3e106170528aa3c (you can skip to the end of the patch if you don't want to follow the entire flow of the code) Does this help express the idea any better? -- Peace and Blessings, -Scott. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
