Its been more than 2 years since my last post. Life has been colorful meanwhile, and I plan on making a return. This post is just a heartbeat to let people know that I am still alive.
Monday, March 14, 2016
Tuesday, October 15, 2013
Counterstrike Server lookup in python
Wrote this script in leisure time long time ago to look up counterstrike servers in my college network. Designed for CZERO, modificiation required for version 1.6, enjoy and edit as per need.
Tuesday, April 16, 2013
Travels from the prison of $ to the realm of # [PART 1]
Beginning Notes:
1. A modest amount of core knowledge is assumed.
2. A read of "Smashing The Stack for Fun and Profit" by Aleph One would be recommeded.
3. Point '2' doesn't guarante anything and for further queries refer to point '1' or ask away under comments.
To get the # symbol at a console is a local exploit's dream. But in the current privelaged land of root, it is not uncommon to face challanges. Lets take a simple example: a setuid root binary, data read from a file and echoed onto the stdout. Lets make this a little easier: the binary is not stripped. Lets make this a little more easier: ASLR & Stack Cookies are disabled... for now. At the same time, it's a 64 bit system, NX is enabled [Hardware Enforced] & we don't have the code.
Enough talking, lets get our hands dirty...
A sample run:
$> ./test
usage: ./test file_name
$> echo "hello" > foo
$> ./test foo
Data Read: hello
looks good, the program takes a filename as input, reads the file and echos the file contents on stdout.
lets try to spice it up a bit, run the program with input incremented by 100 characters each time:
for the character stream generation, we shall use good ol' python.
$> python -c "print 'A'*100" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*200" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
$> python -c "print 'A'*300" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Seems good till now, maybe the code isn't vulnerable, but that wouldn't be fun would it ;)
lets keep trying...
$> python -c "print 'A'*400" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*500" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
Maybe this is a lost cause, we might as well go and check our email...
"Patience my padawan learner"
$> python -c "print 'A'*600" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Segmentation Fault (core dumped)
bullseye! segfault, the buffer doesn't seem to be unlimited afterall.
Looking at all the attempts, we can easily say that the buffer lies between 500 to 600 bytes.
Lets fireup GDB for a bit of code and stack analysis.
$> gdb test
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/sandman/test...(no debugging symbols found)...done.
(gdb) run foo
Starting program: /home/sandman/test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Program received signal SIGSEGV, Segmentation fault.
0x00000000004007af in echo_me ()
Seems like the code segfaults in the function echo_me(), a little bit of disassembly required (thankfully the binary is not stripped)...
(gdb) disas echo_me
Dump of assembler code for function echo_me:
0x00000000004006d4 <+0>: push %rbp
0x00000000004006d5 <+1>: mov %rsp,%rbp
0x00000000004006d8 <+4>: sub $0x240,%rsp
0x00000000004006df <+11>: mov %rdi,-0x238(%rbp)
0x00000000004006e6 <+18>: mov $0x4008ec,%edx
0x00000000004006eb <+23>: mov -0x238(%rbp),%rax
0x00000000004006f2 <+30>: mov %rdx,%rsi
0x00000000004006f5 <+33>: mov %rax,%rdi
0x00000000004006f8 <+36>: callq 0x4005b0
0x00000000004006fd <+41>: mov %rax,0x20053c(%rip) # 0x600c40
0x0000000000400704 <+48>: mov 0x200535(%rip),%rax # 0x600c40
0x000000000040070b <+55>: test %rax,%rax
0x000000000040070e <+58>: jne 0x400724
0x0000000000400710 <+60>: mov $0x4008ee,%edi
0x0000000000400715 <+65>: callq 0x400580
0x000000000040071a <+70>: mov $0xffffffff,%edi
0x000000000040071f <+75>: callq 0x4005a0
0x0000000000400724 <+80>: mov 0x200515(%rip),%rax # 0x600c40
0x000000000040072b <+87>: mov $0x2,%edx
0x0000000000400730 <+92>: mov $0x0,%esi
0x0000000000400735 <+97>: mov %rax,%rdi
0x0000000000400738 <+100>: callq 0x400590
0x000000000040073d <+105>: mov 0x2004fc(%rip),%rax # 0x600c40
0x0000000000400744 <+112>: mov %rax,%rdi
0x0000000000400747 <+115>: callq 0x400570
0x000000000040074c <+120>: mov %eax,-0x4(%rbp)
0x000000000040074f <+123>: mov 0x2004ea(%rip),%rax # 0x600c40
0x0000000000400756 <+130>: mov $0x0,%edx
0x000000000040075b <+135>: mov $0x0,%esi
0x0000000000400760 <+140>: mov %rax,%rdi
0x0000000000400763 <+143>: callq 0x400590
0x0000000000400768 <+148>: mov 0x2004d1(%rip),%rdx # 0x600c40
0x000000000040076f <+155>: mov -0x4(%rbp),%ecx
0x0000000000400772 <+158>: lea -0x230(%rbp),%rax
0x0000000000400779 <+165>: mov %ecx,%esi
0x000000000040077b <+167>: mov %rax,%rdi
0x000000000040077e <+170>: callq 0x4005d0
0x0000000000400783 <+175>: mov 0x2004b6(%rip),%rax # 0x600c40
0x000000000040078a <+182>: mov %rax,%rdi
0x000000000040078d <+185>: callq 0x4005e0
0x0000000000400792 <+190>: mov $0x4008fa,%eax
0x0000000000400797 <+195>: lea -0x230(%rbp),%rdx
0x000000000040079e <+202>: mov %rdx,%rsi
0x00000000004007a1 <+205>: mov %rax,%rdi
0x00000000004007a4 <+208>: mov $0x0,%eax
0x00000000004007a9 <+213>: callq 0x400560
0x00000000004007ae <+218>: leaveq
=> 0x00000000004007af <+219>: retq
End of assembler dump.
(gdb)
looking at the disassembly, its quite easy to get an idea of the code by a simple follow of the important @plt [procedure linkage table] calls...
function echo_me(){
fopen(file) | open the file
fseek(till EOF) --|
ftell(file_des) |--> to calculate the length of the file
fseek(till BOF) --|
fgets(the string from the file) | get the string from the file and store it in the buffer [the vulnerability lies here]
fclose(file) | close the file
printf(the string) | print the string
}
looking at all this it is evident what the programmer has done. A buffer with a static size was defined, the file size was calculated and was read into the buffer. Finally, the buffer is displayed as the output.
1. A modest amount of core knowledge is assumed.
2. A read of "Smashing The Stack for Fun and Profit" by Aleph One would be recommeded.
3. Point '2' doesn't guarante anything and for further queries refer to point '1' or ask away under comments.
To get the # symbol at a console is a local exploit's dream. But in the current privelaged land of root, it is not uncommon to face challanges. Lets take a simple example: a setuid root binary, data read from a file and echoed onto the stdout. Lets make this a little easier: the binary is not stripped. Lets make this a little more easier: ASLR & Stack Cookies are disabled... for now. At the same time, it's a 64 bit system, NX is enabled [Hardware Enforced] & we don't have the code.
Enough talking, lets get our hands dirty...
A sample run:
$> ./test
usage: ./test file_name
$> echo "hello" > foo
$> ./test foo
Data Read: hello
looks good, the program takes a filename as input, reads the file and echos the file contents on stdout.
lets try to spice it up a bit, run the program with input incremented by 100 characters each time:
for the character stream generation, we shall use good ol' python.
$> python -c "print 'A'*100" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*200" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
$> python -c "print 'A'*300" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Seems good till now, maybe the code isn't vulnerable, but that wouldn't be fun would it ;)
lets keep trying...
$> python -c "print 'A'*400" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
$> python -c "print 'A'*500" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... [OUTPUT TRUNCATED]
Maybe this is a lost cause, we might as well go and check our email...
"Patience my padawan learner"
$> python -c "print 'A'*600" > foo && ./test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Segmentation Fault (core dumped)
bullseye! segfault, the buffer doesn't seem to be unlimited afterall.
Looking at all the attempts, we can easily say that the buffer lies between 500 to 600 bytes.
Lets fireup GDB for a bit of code and stack analysis.
$> gdb test
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /home/sandman/test...(no debugging symbols found)...done.
(gdb) run foo
Starting program: /home/sandman/test foo
Data Read: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
Program received signal SIGSEGV, Segmentation fault.
0x00000000004007af in echo_me ()
Seems like the code segfaults in the function echo_me(), a little bit of disassembly required (thankfully the binary is not stripped)...
(gdb) disas echo_me
Dump of assembler code for function echo_me:
0x00000000004006d4 <+0>: push %rbp
0x00000000004006d5 <+1>: mov %rsp,%rbp
0x00000000004006d8 <+4>: sub $0x240,%rsp
0x00000000004006df <+11>: mov %rdi,-0x238(%rbp)
0x00000000004006e6 <+18>: mov $0x4008ec,%edx
0x00000000004006eb <+23>: mov -0x238(%rbp),%rax
0x00000000004006f2 <+30>: mov %rdx,%rsi
0x00000000004006f5 <+33>: mov %rax,%rdi
0x00000000004006f8 <+36>: callq 0x4005b0
0x00000000004006fd <+41>: mov %rax,0x20053c(%rip) # 0x600c40
0x0000000000400704 <+48>: mov 0x200535(%rip),%rax # 0x600c40
0x000000000040070b <+55>: test %rax,%rax
0x000000000040070e <+58>: jne 0x400724
0x0000000000400710 <+60>: mov $0x4008ee,%edi
0x0000000000400715 <+65>: callq 0x400580
0x000000000040071a <+70>: mov $0xffffffff,%edi
0x000000000040071f <+75>: callq 0x4005a0
0x0000000000400724 <+80>: mov 0x200515(%rip),%rax # 0x600c40
0x000000000040072b <+87>: mov $0x2,%edx
0x0000000000400730 <+92>: mov $0x0,%esi
0x0000000000400735 <+97>: mov %rax,%rdi
0x0000000000400738 <+100>: callq 0x400590
0x000000000040073d <+105>: mov 0x2004fc(%rip),%rax # 0x600c40
0x0000000000400744 <+112>: mov %rax,%rdi
0x0000000000400747 <+115>: callq 0x400570
0x000000000040074c <+120>: mov %eax,-0x4(%rbp)
0x000000000040074f <+123>: mov 0x2004ea(%rip),%rax # 0x600c40
0x0000000000400756 <+130>: mov $0x0,%edx
0x000000000040075b <+135>: mov $0x0,%esi
0x0000000000400760 <+140>: mov %rax,%rdi
0x0000000000400763 <+143>: callq 0x400590
0x0000000000400768 <+148>: mov 0x2004d1(%rip),%rdx # 0x600c40
0x000000000040076f <+155>: mov -0x4(%rbp),%ecx
0x0000000000400772 <+158>: lea -0x230(%rbp),%rax
0x0000000000400779 <+165>: mov %ecx,%esi
0x000000000040077b <+167>: mov %rax,%rdi
0x000000000040077e <+170>: callq 0x4005d0
0x0000000000400783 <+175>: mov 0x2004b6(%rip),%rax # 0x600c40
0x000000000040078a <+182>: mov %rax,%rdi
0x000000000040078d <+185>: callq 0x4005e0
0x0000000000400792 <+190>: mov $0x4008fa,%eax
0x0000000000400797 <+195>: lea -0x230(%rbp),%rdx
0x000000000040079e <+202>: mov %rdx,%rsi
0x00000000004007a1 <+205>: mov %rax,%rdi
0x00000000004007a4 <+208>: mov $0x0,%eax
0x00000000004007a9 <+213>: callq 0x400560
0x00000000004007ae <+218>: leaveq
=> 0x00000000004007af <+219>: retq
End of assembler dump.
(gdb)
looking at the disassembly, its quite easy to get an idea of the code by a simple follow of the important @plt [procedure linkage table] calls...
function echo_me(){
fopen(file) | open the file
fseek(till EOF) --|
ftell(file_des) |--> to calculate the length of the file
fseek(till BOF) --|
fgets(the string from the file) | get the string from the file and store it in the buffer [the vulnerability lies here]
fclose(file) | close the file
printf(the string) | print the string
}
looking at all this it is evident what the programmer has done. A buffer with a static size was defined, the file size was calculated and was read into the buffer. Finally, the buffer is displayed as the output.
Tuesday, February 12, 2013
amixer vs alsamixer: Master channel
A convenient method to change the Master volume that I use is via a custom KISS bash script that essentially calls amixer. One curious observation I made was that the return value of amixer for the Master channel did not correlate with alsamixer. A small research reveals why:
from the alsa-devel mailing list:
The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element. Thus showing 89% is correct. It's 10% down from 100%
(1% is because of the resolution of the raw values).
Now, alsamixer shows the percentage in a different way. It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.
* The mapping is designed so that the position in the interval is proportional
* to the volume as a human ear would perceive it (i.e., the position is the
* cubic root of the linear sample multiplication factor). For controls with
* a small range (24 dB or less), the mapping is linear in the dB values so
* that each step has the same size visually. Only for controls without dB
* information, a linear mapping of the hardware volume register values is used
* (this is the same algorithm as used in the old alsamixer).
The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.
Original discussion is here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-March/050146.html
The script itself:
#!/bin/bash
##Amixer Script.
if [ $1 -eq 1 ]
then
amixer set Master 5%+
notify-send "Volume Increase +5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
if [ $1 -eq 2 ]
then
amixer set Master 5%-
notify-send "Volume Decrease -5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
#if [ $1 -eq 0 ]
#then
# amixer set Master toggle
# notify-send "Volume Master Toggle:" "Master Volume Level: "
#fi
#EOF
Running with arguments 1,2 or 0 increases, decreases or toggles(Mute) the Master channel respectively. I don't use the toggle segment thus its commented out.
from the alsa-devel mailing list:
The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element. Thus showing 89% is correct. It's 10% down from 100%
(1% is because of the resolution of the raw values).
Now, alsamixer shows the percentage in a different way. It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.
* The mapping is designed so that the position in the interval is proportional
* to the volume as a human ear would perceive it (i.e., the position is the
* cubic root of the linear sample multiplication factor). For controls with
* a small range (24 dB or less), the mapping is linear in the dB values so
* that each step has the same size visually. Only for controls without dB
* information, a linear mapping of the hardware volume register values is used
* (this is the same algorithm as used in the old alsamixer).
The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.
Original discussion is here:
http://mailman.alsa-project.org/pipermail/alsa-devel/2012-March/050146.html
The script itself:
#!/bin/bash
##Amixer Script.
if [ $1 -eq 1 ]
then
amixer set Master 5%+
notify-send "Volume Increase +5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
if [ $1 -eq 2 ]
then
amixer set Master 5%-
notify-send "Volume Decrease -5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"
fi
#if [ $1 -eq 0 ]
#then
# amixer set Master toggle
# notify-send "Volume Master Toggle:" "Master Volume Level: "
#fi
#EOF
Running with arguments 1,2 or 0 increases, decreases or toggles(Mute) the Master channel respectively. I don't use the toggle segment thus its commented out.
Sunday, February 10, 2013
Linux in 2013, systemd, kernel regressions etc etc...
It has been a very busy time for me, exams on one side and setting up Arch all over again on the other. Somehow I got upto 70% of the work done reinstalling, configuring, rewritting and theming but thankfully the worst is out of the way. I know that because before I reinstalled Arch, I assumed a lot of things about the procedure from earlier experience but the reality was close to shocking, see below.
1. Arch installer removed, all steps are to be done by the user.
2. Bye sysvinit! Hello systemd
3. Kernel Power Regressions. !!
4. HDD APM Issue. !!
5. Openbox updated to 3.5
6. Kernel Ver. @ 3.7.6
7. Since I had newer hardware with dual GPUs [Hybrid Graphics/Optimus], I had to rewrite conky and many scripts due to many low level changes.
Now Im not saying that all of this was bad, actually upgrades like systemd were much of a welcome, anyway what follows is a rundown of each and what I did to counter/resolve the issues.
1. Not much of an issue actually, to be honest, I liked the fact that the installer now required the user to customize manually. Helps in the optimization of the system also as a secondary bonus, the packages installed are always the latest since the new installer "pacstrap" downloaded the latest package versions as compared to installing directly from the Live Media.
2. This was a big surprise, whatever I knew about the original rc.conf sysvinit boot system had to be washed and relearnt with systemd in mind. Mind you, systemd is a boon! Bootup times have been slashed due to the efficient parallelization implemented which contrasts from the original init sequential boot proccess. Also systemd allowed for a much neater boot process modification and the entire start|stop sequence is much cleaner. Although it takes a while to get used to but once you do, creating your own service/tmpfiles becomes a breeze. Also syslogd is now replaced with a journel which can be accessed through the systemctl command. Actually all one needs to use is the systemctl command!
3. These "issues" are actually fixed in the 3.8.x RC versions which are yet to be tested and marked stable but we will get there. The issues Im talking about affect the sandybridge (and possibly ivy too!) line of CPUs. CPU frequency scaling gets locked at maximum frequency w/o turbo boost (Thank god!). In my case (2670QM) the scaling clocks reported to be the lowest clock possible: 800 MHz, but a look at the current clocks proved that they were actually stuck at 2.2 GHZ. Also, on the integrated GPU end, RC6 (powersaving) state was not being initialized. What really frustrated me further that temperatures were 10-15 degrees (Celsius) higher than in Windows. This tends to happen randomly per boot and will be fixed once 3.8 is available as stable. Tip: If you cant wait, check the links at the end of the post for RC(Release Candidate) versions of the kernel.
#] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
#] cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2201000
4. This was the most annoying/frustrating issue I have ever had. Not because it was difficult to fix but because of the everlasting effect it may have had on my HDD. Before I say more, understand that its not really Linux's fault, read on. Long story short, 2.5" HDDs implement shady power saving mechanisms such as head parking and spinning down the spindle motor during an I/O idle session. Furthermore the smart brass at WDC decided to choose power saving over HDD lifespan. How they achieved this was by implementing something called intellipark, which essentially parks the head whenever it senses that I/O is idling. Sometimes this is done in less than 8 seconds. What this results in is a constant "clicking" sound from the HDD and the slow but eventual degradation in head quality which could lead to HDD failure. If that is not enough, the slowdown of the spindle motor puts pressure on it because to spin up the motor for an I/O active session it requires throwing in more power and not to mention stresses the motor further (Newton's first law!).
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 455
193 Load_Cycle_Count 0x0032 155 155 000 Old_age Always - 136465
Checking SMART data on the HDD showed that the current LOAD_CYCLE_COUNT (Number of parks) had jumped to 136465 in less than a year. To put this in perspective, an average 2.5" HDD has a lifetime of 300000 - 600000 parks. Way to go WDC!
I would also like to add that a similar but slightly less annoying effect was also visible when running Windows 7. Thankfully Linux has a tool [hdparm] which allows modifying many variables on the HDD directly such as the APM(Advanced Power Management) value. My original value was 96, which then I changed to 254 to basically kill all possible forms of APM. Did it work?
Yes! :-)
5. Not new and also not much of an issue, openbox 3.4 config is a drop in replacement for 3.5.
6. Kernel is currently at 3.7.6, nice and fast with major fixes but with the power regressions.
7. As previously mentioned in an older post, this was somewhat of a new laptop, modifying old scripts/configs took some time, had to scale conky config and other scripts to take into i7's quad cores plus inclusion of NVIDIA GPU temperature monitoring thanks to the free nouveau driver which enabled basic power management.
Optimus is still not a fully functional componenet in Linux but thanks to projects such as bumblebee, enabling hybrid graphics support was relatively easy.
So thats pretty much it, Im looking forward to checking out how tools such as Metasploit, Nmap etc have improved.
Any questions/comments... insults??
Ref:
Kernel Power Regressions:
: https://bbs.archlinux.org/viewtopic.php?id=150743 //RC Versions in this thread
: https://wiki.archlinux.org/index.php/Intel_Graphics#Module-based_Powersaving_Options
HDD APM Issue:
: https://bbs.archlinux.org/viewtopic.php?id=39258
: https://wiki.archlinux.org/index.php/Hdparm#Parking_your_hard_drive
: http://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
: http://forums.anandtech.com/showthread.php?t=2085685
Systemd:
: https://wiki.archlinux.org/index.php/Systemd
1. Arch installer removed, all steps are to be done by the user.
2. Bye sysvinit! Hello systemd
3. Kernel Power Regressions. !!
4. HDD APM Issue. !!
5. Openbox updated to 3.5
6. Kernel Ver. @ 3.7.6
7. Since I had newer hardware with dual GPUs [Hybrid Graphics/Optimus], I had to rewrite conky and many scripts due to many low level changes.
Now Im not saying that all of this was bad, actually upgrades like systemd were much of a welcome, anyway what follows is a rundown of each and what I did to counter/resolve the issues.
1. Not much of an issue actually, to be honest, I liked the fact that the installer now required the user to customize manually. Helps in the optimization of the system also as a secondary bonus, the packages installed are always the latest since the new installer "pacstrap" downloaded the latest package versions as compared to installing directly from the Live Media.
2. This was a big surprise, whatever I knew about the original rc.conf sysvinit boot system had to be washed and relearnt with systemd in mind. Mind you, systemd is a boon! Bootup times have been slashed due to the efficient parallelization implemented which contrasts from the original init sequential boot proccess. Also systemd allowed for a much neater boot process modification and the entire start|stop sequence is much cleaner. Although it takes a while to get used to but once you do, creating your own service/tmpfiles becomes a breeze. Also syslogd is now replaced with a journel which can be accessed through the systemctl command. Actually all one needs to use is the systemctl command!
3. These "issues" are actually fixed in the 3.8.x RC versions which are yet to be tested and marked stable but we will get there. The issues Im talking about affect the sandybridge (and possibly ivy too!) line of CPUs. CPU frequency scaling gets locked at maximum frequency w/o turbo boost (Thank god!). In my case (2670QM) the scaling clocks reported to be the lowest clock possible: 800 MHz, but a look at the current clocks proved that they were actually stuck at 2.2 GHZ. Also, on the integrated GPU end, RC6 (powersaving) state was not being initialized. What really frustrated me further that temperatures were 10-15 degrees (Celsius) higher than in Windows. This tends to happen randomly per boot and will be fixed once 3.8 is available as stable. Tip: If you cant wait, check the links at the end of the post for RC(Release Candidate) versions of the kernel.
#] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
#] cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2201000
4. This was the most annoying/frustrating issue I have ever had. Not because it was difficult to fix but because of the everlasting effect it may have had on my HDD. Before I say more, understand that its not really Linux's fault, read on. Long story short, 2.5" HDDs implement shady power saving mechanisms such as head parking and spinning down the spindle motor during an I/O idle session. Furthermore the smart brass at WDC decided to choose power saving over HDD lifespan. How they achieved this was by implementing something called intellipark, which essentially parks the head whenever it senses that I/O is idling. Sometimes this is done in less than 8 seconds. What this results in is a constant "clicking" sound from the HDD and the slow but eventual degradation in head quality which could lead to HDD failure. If that is not enough, the slowdown of the spindle motor puts pressure on it because to spin up the motor for an I/O active session it requires throwing in more power and not to mention stresses the motor further (Newton's first law!).
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 455
193 Load_Cycle_Count 0x0032 155 155 000 Old_age Always - 136465
Checking SMART data on the HDD showed that the current LOAD_CYCLE_COUNT (Number of parks) had jumped to 136465 in less than a year. To put this in perspective, an average 2.5" HDD has a lifetime of 300000 - 600000 parks. Way to go WDC!
I would also like to add that a similar but slightly less annoying effect was also visible when running Windows 7. Thankfully Linux has a tool [hdparm] which allows modifying many variables on the HDD directly such as the APM(Advanced Power Management) value. My original value was 96, which then I changed to 254 to basically kill all possible forms of APM. Did it work?
Yes! :-)
5. Not new and also not much of an issue, openbox 3.4 config is a drop in replacement for 3.5.
6. Kernel is currently at 3.7.6, nice and fast with major fixes but with the power regressions.
7. As previously mentioned in an older post, this was somewhat of a new laptop, modifying old scripts/configs took some time, had to scale conky config and other scripts to take into i7's quad cores plus inclusion of NVIDIA GPU temperature monitoring thanks to the free nouveau driver which enabled basic power management.
Optimus is still not a fully functional componenet in Linux but thanks to projects such as bumblebee, enabling hybrid graphics support was relatively easy.
So thats pretty much it, Im looking forward to checking out how tools such as Metasploit, Nmap etc have improved.
Any questions/comments... insults??
Ref:
Kernel Power Regressions:
: https://bbs.archlinux.org/viewtopic.php?id=150743 //RC Versions in this thread
: https://wiki.archlinux.org/index.php/Intel_Graphics#Module-based_Powersaving_Options
HDD APM Issue:
: https://bbs.archlinux.org/viewtopic.php?id=39258
: https://wiki.archlinux.org/index.php/Hdparm#Parking_your_hard_drive
: http://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
: http://forums.anandtech.com/showthread.php?t=2085685
Systemd:
: https://wiki.archlinux.org/index.php/Systemd
Subscribe to:
Posts (Atom)