Tuesday, December 31, 2013
Friday, June 28, 2013
What SELinux is not!
If you're interested about the benefits of running SELinux, probably you read the some of documentations where was written something like that:
But what this exactly means? Where is the beginning and ends the SELinux protection? To better answering those questions I show two examples, where SELinux is work (block) and where is not. This examples is are a buffer overflow and shellcode. But first we must build a test domain where we can test this examples.
The test domain has a minimal privileges to run a simple process via normal system user (and SELinux user "user_u"). We will create a new TE domain as a SELinux policy module. This domain is called process_test_t and we run our two codes example - the buffer overflow and shellcode.
File prosess_test.te:
module process_test 0.1;
require {
type user_t;
attribute domain,application_domain_type,ubac_constrained_type,file_type,exec_type,entry_type,non_security_file_type,application_exec_type;
class file { execute entrypoint };
class process { transition sigchld };
}
type process_test_t,
domain,
application_domain_type,
ubac_constrained_type;
type process_test_exec_t,
file_type,
exec_type,
entry_type,
non_security_file_type,
application_exec_type;
type_transition user_t process_test_exec_t:process process_test_t;
role user_r types { process_test_exec_t process_test_t };
allow user_t process_test_t:process transition;
allow process_test_t process_test_exec_t:file entrypoint;
allow process_test_t user_t:process sigchld;
# for terminal
require {
type user_devpts_t,sshd_t;
class chr_file { read write getattr };
class fd { use };
class process { rlimitinh siginh noatsecure };
}
This is a buffer overflow code. Save it into process_test.c file in process_test directory.
1 #include <stdio.h>
2 #include <string.h>
3
4 #define TEST
5
6 char *get_correct_pass ()
7 {
8 return (char*)"5pW1";
9 }
10
11 int auth ( char *pass )
12 {
13 int _auth = 0;
14 char buff[10];
15 memset( buff,0,10 );
16 strcpy( buff, pass );
17
18 if ( strcmp( buff,get_correct_pass() ) == 0 )
19 _auth = 1;
20
21 return _auth;
22 }
23
24 int main ( int argc, char * argv[] )
25 {
26 if ( auth( argv[1] ) )
27 printf ("access\n");
28 else
29 printf ("denied\n");
30 #ifdef TEST
31 getchar();
32 #endif
33 return 0;
34 }
Now I little describe this code. This program get a one parameter from line command. This parameter is a passwords. If passwords is correct the program print "access" otherwise print "denied". Correct password is defined in line number 8 ("5pW1").
In line 4 we have TEST declaration, if TEST is declared the program will be wait for a key press (line 31).
The most important function is an auth (line 11). In this function first is declared variable _auth. Second variable is a buff, is having lenght 10 characters.
Because variable buff is declared as second it is above in memory than _auth. This is the reason why overwriting the buff can write the _auth variable (line 16). Program give "access" when function auth() return true (line 26) but any value beyond 0 it's mean TRUE. So if you overwrite _auth variable in some character, each of them have diffrent code from 0.
Let's see in a debugger how overwriting it's work, but before we must compile the code:
test1@SELinux:~/process_test$ gcc -g process_test.c -o process_test
Now we check how to the hex value of "E" character, because I use this character for the test as password.
$ echo 'EEEEEEEEEE' | hexdump
0000000 4545 4545 4545 4545 4545
Now we run this program in gdb, as parameter we type this password "EEEEEEEEEE" (10x'E').
test1@SELinux:~/process_test$ gdb process_test
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/test1/process_test/process_test...done.
(gdb) list 1
1 #include <stdio.h>
2 #include <string.h>
3
4 #define TEST
5
6 char *get_correct_pass ()
7 {
8 return (char*)"5pW1";
9 }
10
(gdb) list
11 int auth ( char *pass )
12 {
13 int _auth = 0;
14 char buff[10];
15 memset( buff,0,10 );
16 strcpy( buff, pass );
17
18 if ( strcmp( buff,get_correct_pass() ) == 0 )
19 _auth = 1;
20
(gdb) break 18
Breakpoint 1 at 0x40066b: file process_test.c, line 18.
(gdb) run EEEEEEEEEE
Ok, in the red we have ten bytes from the buffer (buff). In the green we have four bytes from the _auth. A distance between them is a two bytes. So, enough add 3 characters in the password to overwrite _auth e.g.:
test1@SELinux:~/process_test$ ./process_test EEEEEEEEEEbbX
access
test1@SELinux:~/process_test$
The answer is in the architecture of operating system. Everything what is going during the buffer overflow technique (at running ./process_test) is going in the process space. This technique is not required interactions with the kernel.
The next examples is better explains that.
This is a shellcode:
char SC[] = "\xeb\x1d\x5b\x31\xc0\x67\x89\x43\x07\x67\x89\x5b\x08\x67\x89\x43\x0c"\
"\x31\xc0\xb0\x0b\x67\x8d\x4b\x08\x67\x8d\x53\x0c\xcd\x80\xe8\xde\xff"\
"\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4e\x41\x41\x41\x41\x42\x42\x42"\
"\x42";
int
main (int argc, char **argv)
{
int (*ret)();
ret = (int(*)())SC;
(int)(*ret)();
exit(0);
}
Description of this exploit tells that code execute system function execve(/bin/sh), but how we can check this? We must compile it and run in gdb.
Before we must save this code in shellcode.c.
test1@SELinux:~/process_test$ gcc -g shellcode.c -o shellcode
test1@SELinux:~/process_test$ gdb -q ./shellcode
Reading symbols from /home/test1/process_test/shellcode...done.
(gdb) list 1
1 char SC[] = "\xeb\x1d\x5b\x31\xc0\x67\x89\x43\x07\x67\x89\x5b\x08\x67\x89\x43\x0c"\
2 "\x31\xc0\xb0\x0b\x67\x8d\x4b\x08\x67\x8d\x53\x0c\xcd\x80\xe8\xde\xff"\
3 "\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4e\x41\x41\x41\x41\x42\x42\x42"\
4 "\x42";
5
6 int
7 main (int argc, char **argv)
8 {
9 int (*ret)();
10 ret = (int(*)())SC;
(gdb) disas SC
Dump of assembler code for function SC:
0x00000000006008c0 <SC+0>: jmp 0x6008df <SC+31>
0x00000000006008c2 <SC+2>: pop %rbx
0x00000000006008c3 <SC+3>: xor %eax,%eax
0x00000000006008c5 <SC+5>: addr32 mov %eax,0x7(%ebx)
0x00000000006008c9 <SC+9>: addr32 mov %ebx,0x8(%ebx)
0x00000000006008cd <SC+13>: addr32 mov %eax,0xc(%ebx)
0x00000000006008d1 <SC+17>: xor %eax,%eax
0x00000000006008d3 <SC+19>: mov $0xb,%al
0x00000000006008d5 <SC+21>: addr32 lea 0x8(%ebx),%ecx
0x00000000006008d9 <SC+25>: addr32 lea 0xc(%ebx),%edx
0x00000000006008dd <SC+29>: int $0x80
0x00000000006008df <SC+31>: callq 0x6008c2 <SC+2>
0x00000000006008e4 <SC+36>: (bad)
0x00000000006008e5 <SC+37>: (bad)
0x00000000006008e6 <SC+38>: imul $0x414e6873,0x2f(%rsi),%ebp
0x00000000006008ed <SC+45>: rex.B
0x00000000006008ee <SC+46>: rex.B
0x00000000006008ef <SC+47>: rex.B
0x00000000006008f0 <SC+48>: rex.X
0x00000000006008f1 <SC+49>: rex.X
0x00000000006008f2 <SC+50>: rex.X
0x00000000006008f3 <SC+51>: rex.X add %al,(%rax)
End of assembler dump.
(gdb) q
The next what we do is a compile the shellcode without a process memory protections.
root@SELinux:~# rm /home/test1/process_test/process_test
...
test1@SELinux:~/process_test$ gcc -fno-stack-protector -z execstack shellcode.c -o process_test
...
root@SELinux:~# restorecon -v /home/test1/process_test/process_test
restorecon reset /home/test1/process_test/process_test context user_u:object_r:user_home_t:s0->system_u:object_r:process_test_exec_t:s0
...
test1@SELinux:~/process_test$ ls -lZ process_test
total 24
-rwxr-xr-x. 1 test1 test1 system_u:object_r:process_test_exec_t:s0 6657 Jun 27 21:11 process_test
test1@SELinux:~/process_test$ ./process_test
^C
test1@SELinux:~/process_test$
Summary of this two examples it show the SELinux is a kernel security mechanism that work only if the process (subject) must use of the system calls to do bad things.
Furthermore you must understand that if a process which has SELinux permission to e.g. write in to /etc/passwd will be crack with technique which work only in the process space the SELinux protections it's not stop it. SELinux check only if a particular process can call a particular system function, but not check when it do this.
So SELinux is not see a diffrent between a normal system call from proces (the orginaly code flows) and a crack call from process (an attacker changes the orginaly code flows). Of course the policy must allow this action for this process.
SElinux is not:
- antivirus software
- firewalls
- an all-in-one security solution
But what this exactly means? Where is the beginning and ends the SELinux protection? To better answering those questions I show two examples, where SELinux is work (block) and where is not. This examples is are a buffer overflow and shellcode. But first we must build a test domain where we can test this examples.
Test domain
The test domain has a minimal privileges to run a simple process via normal system user (and SELinux user "user_u"). We will create a new TE domain as a SELinux policy module. This domain is called process_test_t and we run our two codes example - the buffer overflow and shellcode.
File prosess_test.te:
module process_test 0.1;
require {
type user_t;
attribute domain,application_domain_type,ubac_constrained_type,file_type,exec_type,entry_type,non_security_file_type,application_exec_type;
class file { execute entrypoint };
class process { transition sigchld };
}
type process_test_t,
domain,
application_domain_type,
ubac_constrained_type;
type process_test_exec_t,
file_type,
exec_type,
entry_type,
non_security_file_type,
application_exec_type;
type_transition user_t process_test_exec_t:process process_test_t;
role user_r types { process_test_exec_t process_test_t };
allow user_t process_test_t:process transition;
allow process_test_t process_test_exec_t:file entrypoint;
allow process_test_t user_t:process sigchld;
# for terminal
require {
type user_devpts_t,sshd_t;
class chr_file { read write getattr };
class fd { use };
class process { rlimitinh siginh noatsecure };
}
allow process_test_t user_devpts_t:chr_file { read write } ;allow process_test_t sshd_t:fd { use };allow process_test_t user_t:fd { use };allow user_t process_test_t:process { rlimitinh siginh noatsecure } ;
# getchar()allow process_test_t user_devpts_t:chr_file { getattr } ;
File prosess_test.fc:
/home/test1/process_test/process_test -- gen_context(system_u:object_r:process_test_exec_t,s0)
This domain is having only such rights:
root@SELinux:~# sesearch --allow -s process_test_t -d
Found 11 semantic av rules:
allow process_test_t user_devpts_t : chr_file { read write getattr } ;
allow process_test_t sshd_t : fd use ;
allow process_test_t user_t : process sigchld ;
allow process_test_t user_t : fd use ;
allow process_test_t process_test_exec_t : file entrypoint ;
allow process_test_t process_test_t : process { fork sigchld } ;
allow process_test_t process_test_t : file { ioctl read write getattr lock append open } ;
allow process_test_t process_test_t : dir { ioctl read getattr lock search open } ;
allow process_test_t process_test_t : lnk_file { ioctl read getattr lock } ;
allow process_test_t process_test_t : unix_stream_socket { ioctl read write create getattr setattr append bind connect listen accept getopt setopt shutdown } ;
allow process_test_t process_test_t : association sendto ;
So it can't do any bad things and user_u:user_r can run it. The program can run via user_u and wait to user type in a character with getchar().
Ok, now we can build the module. On root (unconfined_t) - in his home directory - create a directory mod_process and write there the two module files: process_test.te and process_test.fc. Then we can compile it:
root@SELinux:~/mod_process_test# make -f /usr/share/selinux/default/include/Makefile process_test.pp
I forget, I do this in Debian Squeeze ;) Remember, you must have install SELinux policy development package.
After build you can load this module:
# semodule -i process_test.pp
Now this command work also with you:
# sesearch --allow -s process_test_t -d
As you can see in the file context (process_test.fc) I choose the location on test code in /home/test1/process_test directory. You can choose different localizations, for test I use system user was called 'test1'. If you choose different location you must change the content in process_test.fc file.
Ok! Now I login as test1 user and create the process_test directory in his home directory:
test1@SELinux:~$ id
uid=1001(test1) gid=1001(test1) groups=1001(test1) context=user_u:user_r:user_t:s0
test1@SELinux:~$ ls -lZd process_test/
drwxr-xr-x. 2 test1 test1 user_u:object_r:user_home_t:s0 4096 Jun 25 21:29 process_test/
Now we can begin the first test.
SELinux and buffer overflow
This is a buffer overflow code. Save it into process_test.c file in process_test directory.
1 #include <stdio.h>
2 #include <string.h>
3
4 #define TEST
5
6 char *get_correct_pass ()
7 {
8 return (char*)"5pW1";
9 }
10
11 int auth ( char *pass )
12 {
13 int _auth = 0;
14 char buff[10];
15 memset( buff,0,10 );
16 strcpy( buff, pass );
17
18 if ( strcmp( buff,get_correct_pass() ) == 0 )
19 _auth = 1;
20
21 return _auth;
22 }
23
24 int main ( int argc, char * argv[] )
25 {
26 if ( auth( argv[1] ) )
27 printf ("access\n");
28 else
29 printf ("denied\n");
30 #ifdef TEST
31 getchar();
32 #endif
33 return 0;
34 }
Now I little describe this code. This program get a one parameter from line command. This parameter is a passwords. If passwords is correct the program print "access" otherwise print "denied". Correct password is defined in line number 8 ("5pW1").
In line 4 we have TEST declaration, if TEST is declared the program will be wait for a key press (line 31).
The most important function is an auth (line 11). In this function first is declared variable _auth. Second variable is a buff, is having lenght 10 characters.
Because variable buff is declared as second it is above in memory than _auth. This is the reason why overwriting the buff can write the _auth variable (line 16). Program give "access" when function auth() return true (line 26) but any value beyond 0 it's mean TRUE. So if you overwrite _auth variable in some character, each of them have diffrent code from 0.
Let's see in a debugger how overwriting it's work, but before we must compile the code:
test1@SELinux:~/process_test$ gcc -g process_test.c -o process_test
Now we check how to the hex value of "E" character, because I use this character for the test as password.
$ echo 'EEEEEEEEEE' | hexdump
0000000 4545 4545 4545 4545 4545
Now we run this program in gdb, as parameter we type this password "EEEEEEEEEE" (10x'E').
test1@SELinux:~/process_test$ gdb process_test
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/test1/process_test/process_test...done.
(gdb) list 1
1 #include <stdio.h>
2 #include <string.h>
3
4 #define TEST
5
6 char *get_correct_pass ()
7 {
8 return (char*)"5pW1";
9 }
10
(gdb) list
11 int auth ( char *pass )
12 {
13 int _auth = 0;
14 char buff[10];
15 memset( buff,0,10 );
16 strcpy( buff, pass );
17
18 if ( strcmp( buff,get_correct_pass() ) == 0 )
19 _auth = 1;
20
(gdb) break 18
Breakpoint 1 at 0x40066b: file process_test.c, line 18.
(gdb) run EEEEEEEEEE
Starting program: /home/test1/process_test/process_test EEEEEEEEEE
Breakpoint 1, auth (pass=0x7fffffffe979 "EEEEEEEEEE") at process_test.c:18
18 if ( strcmp( buff,get_correct_pass() ) == 0 )
(gdb) x/32wx &buff - 0x1
0x7fffffffe636: 0xe9790000 0x7fffffff 0x45450000 0x45454545
0x7fffffffe646: 0x45454545 0x00000000 0xe6700000 0x7fffffff
0x7fffffffe656: 0x06b90000 0x00000040 0xe7580000 0x7fffffff
0x7fffffffe666: 0x00000000 0x00020000 0x00000000 0x00000000
0x7fffffffe676: 0xbc8d0000 0x7ffff7a9 0x00000000 0x00000000
0x7fffffffe686: 0xe7580000 0x7fffffff 0x00000000 0x00020000
0x7fffffffe696: 0x06970000 0x00000040 0x00000000 0x00000000
0x7fffffffe6a6: 0xb6fe0000 0x5e236504 0x0540ad6d 0x00000040
(gdb) x/wx &_auth
0x7fffffffe64c: 0x00000000
(gdb) quit
Breakpoint 1, auth (pass=0x7fffffffe979 "EEEEEEEEEE") at process_test.c:18
18 if ( strcmp( buff,get_correct_pass() ) == 0 )
(gdb) x/32wx &buff - 0x1
0x7fffffffe636: 0xe9790000 0x7fffffff 0x45450000 0x45454545
0x7fffffffe646: 0x45454545 0x00000000 0xe6700000 0x7fffffff
0x7fffffffe656: 0x06b90000 0x00000040 0xe7580000 0x7fffffff
0x7fffffffe666: 0x00000000 0x00020000 0x00000000 0x00000000
0x7fffffffe676: 0xbc8d0000 0x7ffff7a9 0x00000000 0x00000000
0x7fffffffe686: 0xe7580000 0x7fffffff 0x00000000 0x00020000
0x7fffffffe696: 0x06970000 0x00000040 0x00000000 0x00000000
0x7fffffffe6a6: 0xb6fe0000 0x5e236504 0x0540ad6d 0x00000040
(gdb) x/wx &_auth
0x7fffffffe64c: 0x00000000
(gdb) quit
test1@SELinux:~/process_test$ ./process_test EEEEEEEEEEbbX
access
test1@SELinux:~/process_test$
And we have an bingo. So now we know that the buffer overflow it is works. Ok, the next step is a change the context of this program.
root@SELinux:~# matchpathcon /home/test1/process_test/process_test
/home/test1/process_test/process_test system_u:object_r:process_test_exec_t:s0
root@SELinux:~# ls -lZ /home/test1/process_test/process_test
-rwxr-xr-x. 1 test1 test1 user_u:object_r:user_home_t:s0 9159 Jun 26 17:55 /home/test1/process_test/process_test
root@SELinux:~# restorecon -v /home/test1/process_test/process_test
restorecon reset /home/test1/process_test/process_test context user_u:object_r:user_home_t:s0->system_u:object_r:process_test_exec_t:s0
root@SELinux:~# ls -lZ /home/test1/process_test/process_test
-rwxr-xr-x. 1 test1 test1 system_u:object_r:process_test_exec_t:s0 9159 Jun 26 17:55 /home/test1/process_test/process_test
Now we check whether SELinux work in enforcing mode.
root@SELinux:~# getenforce
Enforcing
And the last we can run this program in DTE, and thanks getchar() function (line 31) we can see who context have program at running.
$ ./process_test EEEEEEEEEExx1
access
Don't press the any key and as root type in:
root@SELinux:~# ps -efZ |grep test1
system_u:system_r:sshd_t:s0-s0:c0.c1023 root 1084 1043 0 17:32 ? 00:00:00 sshd: test1 [priv]
system_u:system_r:sshd_t:s0-s0:c0.c1023 test1 1088 1084 0 17:32 ? 00:00:00 sshd: test1@pts/1
user_u:user_r:user_t:s0 test1 1089 1088 0 17:32 pts/1 00:00:00 -bash
user_u:user_r:process_test_t:s0 test1 1163 1089 0 21:48 pts/1 00:00:00 ./process_test EEEEEEEEEExx1
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 1177 1078 0 21:57 pts/0 00:00:00 grep test1
As you can see process_test run in process_test_t domain (DTE). This process is run by test1 user (user_t), but after that it's work in own domain (process_test_t) and user test1 don't have permission to e.g. kill this (own) proces. You can login as test1 user in second shell and try this:
test1@SELinux:~$ ps -A
PID TTY TIME CMD
1089 pts/1 00:00:00 bash
1185 pts/2 00:00:00 bash
1190 pts/2 00:00:00 ps
Even if you get the PID from root shell you still can't kill them:
test1@SELinux:~$ kill -s 15 1163
-bash: kill: (1163) - Permission denied
And you have such log:
# tail /var/log/audit/audit.log
...
type=AVC msg=audit(1372276812.345:10): avc: denied { signal } for pid=1185 comm="bash" scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:process_test_t:s0 tclass=process
...
As you can see the process_test_t domain is very confined. user_t can execute them but can't do anything else - only press the key.
But wait the minute, we run this program in enforcing mode with 13 length password and buffer overflow is work even with SELinux protection. Why this possible?
The answer is in the architecture of operating system. Everything what is going during the buffer overflow technique (at running ./process_test) is going in the process space. This technique is not required interactions with the kernel.
The next examples is better explains that.
SELinux and shellcode
This is a shellcode:
char SC[] = "\xeb\x1d\x5b\x31\xc0\x67\x89\x43\x07\x67\x89\x5b\x08\x67\x89\x43\x0c"\
"\x31\xc0\xb0\x0b\x67\x8d\x4b\x08\x67\x8d\x53\x0c\xcd\x80\xe8\xde\xff"\
"\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4e\x41\x41\x41\x41\x42\x42\x42"\
"\x42";
int
main (int argc, char **argv)
{
int (*ret)();
ret = (int(*)())SC;
(int)(*ret)();
exit(0);
}
Description of this exploit tells that code execute system function execve(/bin/sh), but how we can check this? We must compile it and run in gdb.
Before we must save this code in shellcode.c.
test1@SELinux:~/process_test$ gcc -g shellcode.c -o shellcode
test1@SELinux:~/process_test$ gdb -q ./shellcode
Reading symbols from /home/test1/process_test/shellcode...done.
(gdb) list 1
1 char SC[] = "\xeb\x1d\x5b\x31\xc0\x67\x89\x43\x07\x67\x89\x5b\x08\x67\x89\x43\x0c"\
2 "\x31\xc0\xb0\x0b\x67\x8d\x4b\x08\x67\x8d\x53\x0c\xcd\x80\xe8\xde\xff"\
3 "\xff\xff\x2f\x62\x69\x6e\x2f\x73\x68\x4e\x41\x41\x41\x41\x42\x42\x42"\
4 "\x42";
5
6 int
7 main (int argc, char **argv)
8 {
9 int (*ret)();
10 ret = (int(*)())SC;
(gdb) disas SC
Dump of assembler code for function SC:
0x00000000006008c0 <SC+0>: jmp 0x6008df <SC+31>
0x00000000006008c2 <SC+2>: pop %rbx
0x00000000006008c3 <SC+3>: xor %eax,%eax
0x00000000006008c5 <SC+5>: addr32 mov %eax,0x7(%ebx)
0x00000000006008c9 <SC+9>: addr32 mov %ebx,0x8(%ebx)
0x00000000006008cd <SC+13>: addr32 mov %eax,0xc(%ebx)
0x00000000006008d1 <SC+17>: xor %eax,%eax
0x00000000006008d3 <SC+19>: mov $0xb,%al
0x00000000006008d5 <SC+21>: addr32 lea 0x8(%ebx),%ecx
0x00000000006008d9 <SC+25>: addr32 lea 0xc(%ebx),%edx
0x00000000006008dd <SC+29>: int $0x80
0x00000000006008df <SC+31>: callq 0x6008c2 <SC+2>
0x00000000006008e4 <SC+36>: (bad)
0x00000000006008e5 <SC+37>: (bad)
0x00000000006008e6 <SC+38>: imul $0x414e6873,0x2f(%rsi),%ebp
0x00000000006008ed <SC+45>: rex.B
0x00000000006008ee <SC+46>: rex.B
0x00000000006008ef <SC+47>: rex.B
0x00000000006008f0 <SC+48>: rex.X
0x00000000006008f1 <SC+49>: rex.X
0x00000000006008f2 <SC+50>: rex.X
0x00000000006008f3 <SC+51>: rex.X add %al,(%rax)
End of assembler dump.
(gdb) q
This is a assembler code. In the blue I mark the code which clear EAX register and set in a 0xb hex value. 0xb in decimal number is a 11. In the red I mark the holy grail of understand when SELinux is work. In assembly language instruction 'int 0x80' is used when program wants invoke a system calls. In other words that is means the interrupt, this happens when a code flow is switch into system mode. Only then - when program interaction with the system - SELinux can control the process actions (the subject).
Below is a definitions of the system call numbers in file root/arch/x86/include/asm/unistd_32.h from kernel source. On the blue mark we have the number of execve() function.
#ifndef _ASM_X86_UNISTD_32_H
#define _ASM_X86_UNISTD_32_H
/*
* This file contains the system call numbers.
*/
#define __NR_restart_syscall 0
#define __NR_exit 1
#define __NR_fork 2
#define __NR_read 3
#define __NR_write 4
#define __NR_open 5
#define __NR_close 6
#define __NR_waitpid 7
#define __NR_creat 8
#define __NR_link 9
#define __NR_unlink 10
#define __NR_execve 11
#define __NR_chdir 12
#define __NR_time 13
#define __NR_mknod 14
#define __NR_chmod 15
#define __NR_lchown 16
#define __NR_break 17
#define __NR_oldstat 18
#define __NR_lseek 19
#define __NR_getpid 20The next what we do is a compile the shellcode without a process memory protections.
root@SELinux:~# rm /home/test1/process_test/process_test
...
test1@SELinux:~/process_test$ gcc -fno-stack-protector -z execstack shellcode.c -o process_test
...
restorecon reset /home/test1/process_test/process_test context user_u:object_r:user_home_t:s0->system_u:object_r:process_test_exec_t:s0
...
test1@SELinux:~/process_test$ ls -lZ process_test
total 24
-rwxr-xr-x. 1 test1 test1 system_u:object_r:process_test_exec_t:s0 6657 Jun 27 21:11 process_test
test1@SELinux:~/process_test$ ./process_test
^C
test1@SELinux:~/process_test$
And we have such logs:
root@SELinux:~# tail /var/log/audit/audit.log
...
type=AVC msg=audit(1372360361.357:69779): avc: denied { search } for pid=1221 comm="process_test" name="bin" dev=sda1 ino=562 scontext=user_u:user_r:process_test_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=dir
type=SYSCALL msg=audit(1372360361.357:69779): arch=40000003 syscall=11 per=400000 success=no exit=-13 a0=6008e4 a1=6008ec a2=6008f0 a3=7fff3d5bf1f8 items=0 ppid=1057 pid=1221 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts1 ses=4294967295 comm="process_test" exe="/home/test1/process_test/process_test" subj=user_u:user_r:process_test_t:s0 key=(null)
The process_test runs in process_test_t domain don't have permission to search the /bin directory. Even if it had this permission it don't have permission to execute a bin_t type object and many others permission required to run /bin/sh.
Summary
Summary of this two examples it show the SELinux is a kernel security mechanism that work only if the process (subject) must use of the system calls to do bad things.
Furthermore you must understand that if a process which has SELinux permission to e.g. write in to /etc/passwd will be crack with technique which work only in the process space the SELinux protections it's not stop it. SELinux check only if a particular process can call a particular system function, but not check when it do this.
So SELinux is not see a diffrent between a normal system call from proces (the orginaly code flows) and a crack call from process (an attacker changes the orginaly code flows). Of course the policy must allow this action for this process.
Saturday, June 22, 2013
Historia komputer贸w jakiej nie zna艂e艣
Czy zastanawia艂e艣 si臋 kiedy艣 nad tym, co w艂a艣ciwie dzieje gdy uruchamiasz sw贸j komputer? Wracasz do domu z pracy b膮d藕 szko艂y, bierzesz laptopa, wciskasz przycisk "Power" i czekasz, a偶 za艂aduje si臋 system. Dzi艣 informatyka kojarzona jest z matematyk膮, podobno maj膮 ze sob膮 tak wiele wsp贸lnego. Komputery maj膮 wi臋cej wsp贸lnego z fizyk膮, a konkretnie z elektronik膮. W istocie rzeczy komputery przecie偶 s膮 urz膮dzeniami elektronicznymi. Elektronika powsta艂a na bazie fizyki przy pomocy matematyki, tak samo jak informatyka powsta艂a na bazie elektroniki przy pomocy matematyki. Mniej wi臋cej tak mo偶na zdefiniowa膰 sam膮 informatyk臋, ale na pewno informatyka nie powsta艂a dzi臋ki matematyce, taka informatyka mog艂aby istnie膰 tylko na papierze - i istnia艂a. Informatyka to fizyczne wykorzystanie matematycznych regu艂 przy pomocy elektroniki, r贸wnie dobrze mog艂aby si臋 nazywa膰 "infortronika". Najlepiej pokaza膰 to na przyk艂adzie historii.
Wi臋c to b臋dzie historia o tym, jak komputery dzia艂aj膮, dzi臋ki czemu i komu by艂o mo偶liwe ich zbudowanie. Postaram si臋 r贸wnie偶 pokaza膰, w kt贸rych momentach pomoc matematyki by艂a niezb臋dna, a w kt贸rych fizyki. Co ciekawe w tej historii znajdzie si臋 wiele rzeczy na pierwszy rzut oka nie maj膮cych nic wsp贸lnego z komputerami, wszak cz艂owiek z ma艂p膮 te偶 nie ma nic wsp贸lnego.
Poniewa偶 kompletna historia komputer贸w jest zbyt du偶ym zagadnienie, to w tym tek艣cie ograniczy艂em si臋 do cz臋艣ci informatyki zwanej hardware. Software zostanie tu pomini臋te, poniewa偶 to ju偶 historia system贸w operacyjnych.
Energia
W komputerach jest co艣, co sprawia i偶 o偶ywaj膮. Co ciekawe to samo o偶ywia ludzkie cia艂o, to energia elektryczna. M贸zg steruje Twoimi mi臋艣niami za pomoc膮 impuls贸w elektrycznych, a elektrowstrz膮sy potrafi膮 przywr贸ci膰 cz艂owieka do 偶ycia.
Jak wida膰 mamy wi臋cej wsp贸lnego z komputerami ni偶 nam si臋 wydaje, wszak budujemy je na swoje podobie艅stwo. Uczymy je tego co sami potrafimy by korzysta膰 z ich szybko艣ci i nieomylno艣ci. Jednak ile jest wart Tw贸j komputer bez energii elektrycznej i w艂a艣ciwie czym ona jest?
Dzi臋ki Einsteinowi wiemy, 偶e ka偶dy kawa艂em materii posiada ogromne zasoby energii. Problem w tym, 偶e nadal do ko艅ca nie wiemy jak j膮 wydoby膰. Obecnie najlepiej znanym nam sposobem na wydoby膰 tej energii jest bomba atomowa. Jednak jak wiadomo energia wydobyta w ten spos贸b jest "brudna". Wydaje si臋 偶e obecnie najbardziej znanym nam sposobem na wydobywanie energii jest elektryczno艣膰. Ta r贸wnie偶 nie jest w stu procentach czysta, dlatego obecnie opracowuje si臋 ekologiczne 藕r贸d艂a energii. Jednak elektryczno艣膰 to szczeg贸lna forma energii, kt贸ra wyst臋puje w naturalnym 艣rodowisku, pod takimi postaciami jak 艣wiat艂o i pioruny. Oczywi艣cie, w skali kosmosu energia bomby atomowej r贸wnie偶 wyst臋puje w naturalnej postaci, to np. nasze s艂o艅ce.
Najwa偶niejsze z tego wszystkiego jest to, aby zrozumie膰, i偶 energia nie jest nowym produktem, tylko inn膮 form膮 materii. Tak wi臋c posiadamy ogromne zasoby i pr贸bujemy wydoby膰 z niej energi臋. Gdyby uda艂o nam si臋 wydoby膰 chocia偶 po艂ow臋 rzeczywistej energii z masy jak膮 posiada bateria laptopa, to nasz laptop pracowa艂by jak ameryka艅ski lotniskowce wyposa偶one w dwa reaktory atomowe, kt贸re pozwalaj膮 mu funkcjonowa膰 nawet przez ponad 20 lat.
Pocz膮tki elektryczno艣ci
Elektryczno艣膰 fascynowa艂a ludzi od dawna, ale przez wieki pozostawa艂a poza ich zasi臋giem. Historia ujarzmiania elektryczno艣ci zaczyna si臋 w XVIII wieku. Stephen Gray mieszkaj膮cy w Londynie zbudowa艂 w swoim domu szklan膮 tub臋 i eksperymentowa艂 z elektryczno艣ci膮 statyczn膮, kt贸r膮 wytwarza艂 przyk艂adaj膮c d艂o艅 do szybko obracanej szklanej tuby. Zaobserwowa艂, 偶e elektryczno艣膰 mo偶na wygenerowa膰 przez ruch i potrafi ona porusza膰 przedmioty. W 1732 opublikowa艂 wyniki swoich bada艅, kt贸rych efektem by艂y odkrycie przewodnik贸w i izolator贸w. Do dzi艣 u偶ywamy r贸偶nych metali jako przewodnik贸w i porcelany jako izolatora na s艂upach elektrycznych.
W 1745 Pieter van Musschenbroek, Holenderski naukowiec szuka艂 sposobu na zgromadzenie elektryczno艣ci. Wcze艣niej wiedziano, 偶e cz艂owiek mo偶e j膮 wytworzy膰, ale gdy przestawa艂 to robi膰, natychmiast znika艂a. Wpad艂 na pomys艂, aby poprzez metalowy przew贸d zgromadzi膰 elektryczno艣膰 wytwarzan膮 przez obracaj膮c膮 si臋 szklan膮 tub臋 w wodzie przechowywanej w szklanym naczyniu. Szklane naczynie postawi艂 na materiale, kt贸ry mia艂 w艂a艣ciwo艣ci izolacyjne. Pewnego razu zapomnia艂 to zrobi膰 i trzyma艂 szklany pojemnik w d艂oni, i tak uda艂o mu si臋 zbudowa膰 pierwsze urz膮dzenie na 艣wiecie potrafi膮ce przechowywa膰 elektryczno艣膰. Nazwano je butelk膮 lejdejsk膮 i jest ona przodkiem element贸w elektrycznych znajduj膮cych si臋 dzi艣 w niemal ka偶dym urz膮dzeniu elektronicznym - to kondensator.
Par臋 lat p贸藕niej jeden z za艂o偶ycieli Stan贸w Zjednoczonych Benjamin Franklin dokona艂 eksperymentu polegaj膮cego na na艂adowaniu butelki lejdejskiej za pomoc膮 piorunu. Do 艣rodka butelki w艂o偶y艂 trzy metrowy pr臋t i czeka艂 na burze. Eksperyment powi贸d艂 si臋, jego wynikiem by艂o udowodnienie, 偶e pioruny s膮 t膮 samo elektryczno艣ci膮, kt贸r膮 wytwarza cz艂owiek. Benjamin opr贸cz zrozumienia natury wy艂adowa艅 elektrycznych wyja艣ni艂 r贸wnie偶 zasad臋 dzia艂ania butelki lejdejskiej i stworzy艂 definicje 艂adunk贸w elektrycznych opisuj膮c fundamentalne w艂asno艣ci 艂adunk贸w dodatnich i ujemnych.
W 1800 roku, w艂oski fizyk Alessandro Volta zbudowa艂 pierwsz膮 baterie, zwan膮 stosem Volty. Warto podkre艣li膰, i偶 bateria ta generowa艂a energi臋 z elektrycznych w艂a艣ciwo艣ci dw贸ch r贸偶nych metali, bez udzia艂u jakiegokolwiek 藕r贸d艂a energii zewn臋trznej. Jego wk艂ad w elektryczno艣膰 by艂 tak wa偶ny, 偶e na jego cze艣膰 nazwano jednostk臋 napi臋cia jego nazwiskiem. Dziewi臋膰 lat p贸藕niej brytyjski chemik Humphry Davy zbudowa艂 najwi臋ksz膮 bateri臋 jak膮 do tej pory widziano i przed publiczno艣ci膮 zetkn膮 ze sob膮 dwa ko艅ce kabli pod艂膮czone do tej baterii generuj膮c po raz pierwszy elektryczne 艣wiat艂o wytworzone przez cz艂owieka, kt贸re zapowiada艂o nadej艣cie nowej ery w elektryczno艣ci.
Elektromagnetyzm
Michael Faraday by艂 angielskim samoukiem, kt贸ry interesowa艂 si臋 elektryczno艣ci膮. Uda艂o mu si臋 dosta膰 prac臋 na stanowisku asystent w laboratorium Royal Institution of Great Britain. W 1821 roku zbudowa艂 pierwsze urz膮dzenie, kt贸re jest przodkiem wszystkich obecnych silnik贸w elektrycznych. Odkry艂, 偶e pr膮d generuje pole magnetyczne, a jak wiadomo magnetyzm pozwala porusza膰 przedmioty. To odkrycie by艂o pocz膮tkiem nowej ery, w kt贸rej wa偶niejsze by艂o to, do czego pr膮d mo偶na wykorzysta膰, ni偶 czym w艂a艣ciwie jest. Faraday odkry艂 r贸wnie偶, 偶e proces ten mo偶na odwr贸ci膰. Ruch i magnetyzm m贸g艂 generowa膰 pr膮d. To w艂a艣nie na tej zasadzie dzia艂aj膮 dzisiejsze elektrownie, dzi臋ki kt贸rej teraz dzia艂a Tw贸j komputer. Faraday odkry艂 zjawisko zwane indukcj膮 elektromagnetyczn膮.
Mo偶na by si臋 domy艣le膰, 偶e kolejnym krokiem b臋dzie stworzenie elektrowni i 偶ar贸wki, jednak najpierw stworzono co艣 innego, co艣 co ma wi臋cej wsp贸lnego z komputerem ni偶 by si臋 mog艂o wydawa膰.
Od 1850 roku pr贸bowano po艂膮czy膰 za pomoc膮 kabla 贸wczesne dwa mocarstwa, Angli臋 i Stany Zjednoczone. Pocz膮tkowo uwa偶ano, 偶e po艂o偶enie linii telegraficznej pod Atlantykiem jest niewykonywalne, jednak realne zyski zach臋ci艂y do pr贸b. Ostatecznie w 1859 roku na 艣rodku Atlantyku po艂膮czono ze sob膮 dwa kable, tym samym 艂膮cz膮c ze sob膮 i po raz pierwszy dwa kontynenty.
Niestety komunikaty by艂y ma艂o zrozumiane, odbiorca nie m贸g艂 odr贸偶ni膰 kr贸tkiego sygna艂u od d艂ugiego. Sytuacja okaza艂a si臋 frustruj膮ca. Jakby tego by艂o ma艂o in偶ynierowie postanowili zwi臋kszy膰 napi臋cie, gdy偶 uwa偶ali, 偶e wi臋ksze napi臋cie wygeneruje mocniejszy i wyra藕niejszy sygna艂. Niestety, konsekwencj膮 podniesienia napi臋cia by艂o zniszczenie kabla. Wtedy jeszcze nie do ko艅ca wiedziano nic o fali elektromagnetycznej i jak w艂a艣ciwie pr膮d p艂ynie przez przew贸d. Mimo wszystko po艂o偶enie transatlantyckiego kabla by艂o najwi臋kszym i najdro偶szym eksperymentem z elektryczno艣ci膮.
W ko艅cu w 1866 roku po艂o偶ono nowy kabel, kt贸ry rozwi膮zywa艂 problem zak艂贸ce艅 poprzez zastosowanie ekranowania i ponownie przes艂ano wiadomo艣膰. Tym razem sygna艂 by艂 wyra藕ny i zrozumiany. Pierwszy raz informacja z Wielkiej Brytanii do Stan贸w Zjednoczonych dociera艂a niemal natychmiast zamiast dw贸ch tygodni. Osi膮gni臋cie to by艂o bardziej post臋pem cywilizacyjnym ni偶 technicznym.
Telefon
Nad ide膮 przesy艂ania g艂osu za pomoc膮 elektryczno艣膰 od 1875 roku pracowa艂 Alexander Graham Bell i to on z艂o偶y艂 pierwszy patent na telefon. Jednak to urz膮dzenie mia艂o wielu wsp贸艂tw贸rc贸w. W 1876 roku Alexander dokona艂 pierwszego udanego eksperymentu polegaj膮cego na przes艂aniu d藕wi臋ku: "Mr. Watson come here I want to see you". W kolejnych latach ca艂y czas udoskonalano t膮 technologi臋. Pierwsz膮 rozmow臋 d艂ugodystansow膮 pomi臋dzy Nowym Jorkiem a Kaliforni膮 wykonano dopiero a偶 w 1915 roku, ale jedna z pierwszych, a zarazem najbardziej znanych firm telekomunikacyjnych powsta艂a ju偶 w 1885 roku, to AT&T (American Telephone and Telegraph Company). AT&T odegra jedn膮 ze znacz膮cych r贸l w procesie powstawiania komputer贸w. Teraz ju偶 wiesz, sk膮d wzi臋艂a si臋 nazwa Bell Labs, nazwa laboratorium, w kt贸re mia艂o wielki wp艂yw na powstanie komputer贸w i system贸w operacyjnych.
Dystrybucja energii elektrycznej
Cho膰 Edison nie by艂 jedynym wynalazc膮 偶ar贸wki, to ca艂a chwa艂a przypad艂a jemu. Jednak kluczem do elektrycznego biznesu by艂o generowanie pr膮du i jego dystrybucja do jak najwi臋kszej ilo艣ci odbiorc贸w. Tylko wtedy w pe艂ni mo偶na by艂o zarobi膰 na elektryczno艣ci. W tym momencie historia elektryczno艣ci przestaje mie膰 charakter czysto odkrywczy i nabiera czysto ekonomicznych cech.
W 1882 roku Edison w otoczeniu reporter贸w i bankier贸w zapowiedzia艂 wybudowanie pierwszej elektrowni (ang. power station) na Manhatanie. Stacja zosta艂a uruchomiona w 1890 roku i generowa艂a pr膮d sta艂y (DC). Jednak op艂acalno艣膰 takiego systemu by艂a zerowa, poniewa偶 mog艂a ona dostarcza膰 energi臋 tylko w obr臋bie jednej mili, z powodu strat napi臋cia. System ten by艂 bardzo ograniczony i drogi, a wielka wizja Edisona, w kt贸rej o艣wietli on ca艂y Nowy Jork zosta艂a powstrzymana przez ograniczenia jego systemu.
Wybudowanie elektrowni by艂o wielkim krokiem, pierwszy raz energi臋 mo偶na by艂o kupi膰. Poza tym centralne generowanie pozwala艂o uzyska膰 wi臋ksz膮 efektywno艣ci i ci膮g艂膮 prac臋. Jednak problemy z systemem rozprowadzania energii nie pozwala艂y na ekspansje elektryczno艣ci.
AC vs. DC
Rozwi膮zanie problemu zaproponowa艂 nieznany geniusz, by艂 nim Nikola Tesla. Zaproponowa艂 zupe艂nie inne rozwi膮zanie, by艂o nim generowanie pr膮du przemiennego (AC) poza miastami i dostarczanie do miasta. Tesla nie skupia艂 si臋 tylko na generowaniu pr膮du, opracowa艂 ca艂y system jego dystrybucji. Zalet膮 pr膮du przemiennego jest to, 偶e mo偶na go przesy艂a膰 bez znacznych strat na bardzo du偶e odleg艂o艣ci. Jego wad膮 by艂o to, 偶e wysokie napi臋cia pr膮du przemiennego s膮 niebezpieczne.
Jednak sam Tesla nie by艂 znany, ale jego patentem na generowanie pr膮du przemiennego i jego przetwarzanie na pr膮d sta艂y zainteresowa艂 si臋 George Westinghouse. Odkupi艂 go od Tesla za znaczn膮 kwot臋, oraz za sta艂膮 op艂at臋 od okre艣lonej ilo艣ci sprzedanej energii.
Edison zwalcza艂 pomys艂 Tesla strasz膮c ludzi, tym jak pr膮d przemienny jest niebezpieczny. Organizowa艂 pokazy, w kt贸rych zabija艂 psy, a nawet konie. Wywo艂a艂o to powszechny strach. Edison reklamowa艂 sw贸j produkt jako bezpieczny system. Napi臋cie by艂o du偶e, gdy偶 Thomas Edison i George Westinghouse walczyli o kontrakt na zaopatrzenie Nowego Jorku w pr膮d. Mieli 艣wiadomo艣膰 tego, 偶e przed zwyci臋zc膮 stanie otworem ca艂y rynek.
W odpowiedzi na zab贸jcze dzia艂anie pr膮du przemiennego Tesla r贸wnie偶 przygotowa艂 pokaz, kt贸ry sprawi艂 i偶 ludzie uwierzyli, 偶e pr膮d przemienny o bardzo du偶ych napi臋ciach mo偶e by膰 bezpieczny. Pokaz Nikola Tesla z 1891 roku zmieni艂 bieg historii. W 1896 roku na wodospadzie Niagara zbudowano pierwsz膮 elektrowni臋, kt贸ra par臋 lat p贸藕niej zasili艂a Nowy Jork w energi臋 elektryczn膮. Dzi艣 wszyscy korzystamy z energii elektrycznej dostarczanej systemem Nikola Tesla. Teraz ju偶 wiesz dlatego do komputera potrzebny jest adapter DC.
Jednak historia Nikola Tesla nie ko艅czy si臋 w chwale i bogactwie. Cz艂owiek, kt贸ry pom贸g艂 stworzy膰 dzisiejszy 艣wiat umar艂 biedny i samotny w hotelowym pokoju, a Edison sta艂 si臋 w pewnym sensie bohaterem Ameryki.
Fale
Michael Faraday w 1846 roku powiedzia艂, i偶 艣wiat艂o to jedna z form fali elektromagnetycznych. Publiczno艣膰 go wy艣mia艂a, mimo i偶 by艂 ju偶 wtedy cenionym profesorem. Faraday nie potrafi艂 udowodni膰 swego twierdzenia, potrzebowa艂 kogo艣 kto by mu pom贸g艂. Po pi臋tnastu latach (1861 r.) profesor James Clerk Maxwell natkn膮艂 si臋 na ide臋 Faradaja i uwierzy艂 w ni膮. Postanowi艂 udowodni膰 to matematycznie.
W 1887 roku Heinrich Rudolf Hertz przeprowadzi艂 eksperymenty, kt贸re potwierdzi艂y prawid艂owo艣膰 oblicze艅 wykonanych przez Maxwell'a. W 1894 roku Oliver Lodge po raz pierwszy zaprezentowa艂 urz膮dzenie wykrywaj膮ce fale elektromagnetyczne. Wydarzenie to rozpoczyna now膮 er臋 w komunikacji i nauce.
Nie trudno domy艣li膰 si臋 co by艂o nast臋pstwem odkrycia fal elektromagnetycznych. Guglielmo Marconi jest najbardziej znanym nazwiskiem z wynalezienia radia. Co prawda nie tylko on rozwija艂 t膮 technologi臋 ale to jemu uda艂o si臋 pierwszemu dokona膰 transmisji przez Atlantyk. Jego pierwsze eksperymenty z radiem mia艂y miejsce w 1895 roku, natomiast pierwsza transatlantycka wiadomo艣膰 przez Marconiego mia艂a miejsce w 1902 roku.
Telewizor
Skoro to co widzimy jest 艣wiat艂em, a 艣wiat艂o jest fal膮 elektromagnetyczn膮, kt贸rymi zaczynano manipulowa膰, to mo偶liwe jest rejestrowanie i przesy艂anie obrazu do odbiornika. Tak jak w przypadku telefonu u偶yto greckiego s艂owa "tele", kt贸re oznacza na odleg艂o艣膰. Idea przesy艂ania obrazu na odleg艂o艣膰 powsta艂a mniej wi臋cej w tym samym czasie co przesy艂anie d藕wi臋ku.
Pierwsze urz膮dzenie potrafi膮ce odbiera膰 obraz stworzono w 1906 roku, jednak nie przypomina艂o ono nowoczesnych telewizor贸w kineskopowych. Du偶膮 rol臋 w rozwoju telewizji odegra艂y lampy elektronowe, z kt贸rych w przysz艂o艣ci budowano pierwsze komputery. Pierwsze stacje nadawcze, kt贸re s膮 dzi艣 jednymi z najwi臋kszych na 艣wiecie powstawa艂y na pocz膮tku lat trzydziestych, ale pierwszy przekaz kolorowego obrazu mia艂 miejsce w 1938 roku.
Tranzystor
W 1947 roku w Bell Labs stworzono pierwszy tranzystor. Tranzystor korzysta z fizycznych w艂a艣ciwo艣ci krzemu, kt贸re nazwano p贸艂przewodnikiem. Zasad臋 tranzystora mo偶na opisa膰 nast臋puj膮co. Wyobra藕 sobie, 偶e kawa艂ek p贸艂przewodnika (np. krzemu) 艂膮czy dwa przewody. Za艂贸偶my, 偶e pr膮d nie przep艂ywa przez p贸艂przewodnik. Teraz do krzemu przy艂膮czmy trzeci przew贸d odgrywaj膮cy rol臋 kontrolera. Za pomoc膮 kontrolera ma艂ym napi臋ciem uruchamiamy przewodnictwo wi臋kszych napi臋膰, czyli pozosta艂ych dw贸ch przewod贸w po艂膮czonych z krzemem. Mo偶na to por贸wna膰 do w艂膮cznika 艣wiat艂a, gdzie przycisk pe艂ni rol臋 kontrolera.
Zbudowanie elektronicznego prze艂膮cznika pozwoli艂o skonstruowa膰 logiczne bramki. Np. przy pomocy kilku tranzystor贸w mo偶na zbudowa膰 uk艂ady realizuj膮ce operacje logiczne, takiej jak AND, OR i NOT. Te proste operacje logiczne wraz z arytmetyk膮 binarn膮 s膮 podstawami dzisiejszych procesor贸w. Stworzenie tranzystora rozpoczyna er臋 贸wczesnych komputer贸w oraz ca艂膮 mas臋 urz膮dze艅 elektronicznych.
W 1948 roku Bell Labs opublikowa艂 jeden z najwa偶niejszych dokument贸w dla dzisiejszej komunikacji w sieci. "A Mathematical Theory of Communication", to matematyczne podstawy kodowania informacji przy pomocy urz膮dze艅 elektronicznych.
W 1956 roku John Bardeen, Walter H. Brattain i William Shockley otrzymali nagrod臋 Nobla z fizyki za wk艂ad w stworzenie tranzystora.
Dolina Krzemowa
Zapewne Dolina Krzemowa kojarzy Ci si臋 z informatyczn膮 mekk膮, Google, Facebook, Intel, Microsoft i ca艂膮 reszta wielkich korporacji. Jednak zanim tak si臋 sta艂o miejsce to mia艂o przeznaczenie rolnicze i by艂o pe艂ne owocowych sad贸w.
W 1953 jedne z konstruktor贸w tranzystora William Shockley opu艣ci艂 Bell Labs i za艂o偶y艂 firm臋 produkuj膮c膮 tranzystory zwan膮 Shockley Semiconductor Laboratory. Oczywi艣cie na lokalizacje wybra艂 wspomniane tereny rolnicze. Kolejn膮 oczywisto艣ci膮 jest to, 偶e sam nie m贸g艂 zaj膮膰 si臋 wszystkim, potrzebowa艂 wsp贸艂pracownik贸w. Tak wi臋c zebra艂 najlepszych fizyk贸w, by艂 tam chyba te偶 chemik i matematyk, razem by艂o ich o艣miu (zdradziecka 贸semka).
Podsumowanie
Ot贸偶 ka偶da cz臋艣膰 Twojego laptopa, czy tabletu ma swoich przodk贸w w przedstawionej historii. Ekran, dysk, WiFi, g艂adzik, zasilacz, bateria, g艂o艣niki, kamera, mikrofon, procesor, jednym s艂owem wszystko. Wszystko to sk艂ada si臋 na obecnie jedno z najbardziej z艂o偶onych urz膮dze艅 elektronicznych zwanych komputerem. Ka偶da z tych cz臋艣ci mo偶e dzia艂a膰 tylko dzi臋ki energii elektrycznej. Obecne komputery nie mog艂yby oferowa膰 takiej funkcjonalno艣ci, gdyby wcze艣niej nie wynaleziono 偶ar贸wki, elektrowni, baterii, telefonu, radia, telewizji i w ko艅cu tranzystora. Ka偶dy z tych wynalazk贸w jest cz臋艣ci膮 historii obecnych komputer贸w.
Wi臋c, je偶eli zastanawiasz si臋 jak dzia艂a WiFi, czy procesor, a tym bardziej jakich innowacji niebawem si臋 doczekasz, to w pewnym sensie pytasz o przysz艂o艣膰 urz膮dze艅 elektronicznych, z kt贸rych zbudowany jest Tw贸j komputer.
Ale tryumf elektryczno艣膰 nie ogranicza si臋 do zbudowania komputera przez cz艂owieka. Elektryczno艣膰, a w艂a艣ciwie nasza umiej臋tno艣膰 manipulowania ni膮 zmieni艂a ca艂y nasz dotychczasowy 艣wiat, komputer za艣 jest tylko jedna z form tej rewolucji.
Wi臋c to b臋dzie historia o tym, jak komputery dzia艂aj膮, dzi臋ki czemu i komu by艂o mo偶liwe ich zbudowanie. Postaram si臋 r贸wnie偶 pokaza膰, w kt贸rych momentach pomoc matematyki by艂a niezb臋dna, a w kt贸rych fizyki. Co ciekawe w tej historii znajdzie si臋 wiele rzeczy na pierwszy rzut oka nie maj膮cych nic wsp贸lnego z komputerami, wszak cz艂owiek z ma艂p膮 te偶 nie ma nic wsp贸lnego.
Poniewa偶 kompletna historia komputer贸w jest zbyt du偶ym zagadnienie, to w tym tek艣cie ograniczy艂em si臋 do cz臋艣ci informatyki zwanej hardware. Software zostanie tu pomini臋te, poniewa偶 to ju偶 historia system贸w operacyjnych.
Energia
W komputerach jest co艣, co sprawia i偶 o偶ywaj膮. Co ciekawe to samo o偶ywia ludzkie cia艂o, to energia elektryczna. M贸zg steruje Twoimi mi臋艣niami za pomoc膮 impuls贸w elektrycznych, a elektrowstrz膮sy potrafi膮 przywr贸ci膰 cz艂owieka do 偶ycia.
Jak wida膰 mamy wi臋cej wsp贸lnego z komputerami ni偶 nam si臋 wydaje, wszak budujemy je na swoje podobie艅stwo. Uczymy je tego co sami potrafimy by korzysta膰 z ich szybko艣ci i nieomylno艣ci. Jednak ile jest wart Tw贸j komputer bez energii elektrycznej i w艂a艣ciwie czym ona jest?
Dzi臋ki Einsteinowi wiemy, 偶e ka偶dy kawa艂em materii posiada ogromne zasoby energii. Problem w tym, 偶e nadal do ko艅ca nie wiemy jak j膮 wydoby膰. Obecnie najlepiej znanym nam sposobem na wydoby膰 tej energii jest bomba atomowa. Jednak jak wiadomo energia wydobyta w ten spos贸b jest "brudna". Wydaje si臋 偶e obecnie najbardziej znanym nam sposobem na wydobywanie energii jest elektryczno艣膰. Ta r贸wnie偶 nie jest w stu procentach czysta, dlatego obecnie opracowuje si臋 ekologiczne 藕r贸d艂a energii. Jednak elektryczno艣膰 to szczeg贸lna forma energii, kt贸ra wyst臋puje w naturalnym 艣rodowisku, pod takimi postaciami jak 艣wiat艂o i pioruny. Oczywi艣cie, w skali kosmosu energia bomby atomowej r贸wnie偶 wyst臋puje w naturalnej postaci, to np. nasze s艂o艅ce.
Najwa偶niejsze z tego wszystkiego jest to, aby zrozumie膰, i偶 energia nie jest nowym produktem, tylko inn膮 form膮 materii. Tak wi臋c posiadamy ogromne zasoby i pr贸bujemy wydoby膰 z niej energi臋. Gdyby uda艂o nam si臋 wydoby膰 chocia偶 po艂ow臋 rzeczywistej energii z masy jak膮 posiada bateria laptopa, to nasz laptop pracowa艂by jak ameryka艅ski lotniskowce wyposa偶one w dwa reaktory atomowe, kt贸re pozwalaj膮 mu funkcjonowa膰 nawet przez ponad 20 lat.
Pocz膮tki elektryczno艣ci
Elektryczno艣膰 fascynowa艂a ludzi od dawna, ale przez wieki pozostawa艂a poza ich zasi臋giem. Historia ujarzmiania elektryczno艣ci zaczyna si臋 w XVIII wieku. Stephen Gray mieszkaj膮cy w Londynie zbudowa艂 w swoim domu szklan膮 tub臋 i eksperymentowa艂 z elektryczno艣ci膮 statyczn膮, kt贸r膮 wytwarza艂 przyk艂adaj膮c d艂o艅 do szybko obracanej szklanej tuby. Zaobserwowa艂, 偶e elektryczno艣膰 mo偶na wygenerowa膰 przez ruch i potrafi ona porusza膰 przedmioty. W 1732 opublikowa艂 wyniki swoich bada艅, kt贸rych efektem by艂y odkrycie przewodnik贸w i izolator贸w. Do dzi艣 u偶ywamy r贸偶nych metali jako przewodnik贸w i porcelany jako izolatora na s艂upach elektrycznych.
W 1745 Pieter van Musschenbroek, Holenderski naukowiec szuka艂 sposobu na zgromadzenie elektryczno艣ci. Wcze艣niej wiedziano, 偶e cz艂owiek mo偶e j膮 wytworzy膰, ale gdy przestawa艂 to robi膰, natychmiast znika艂a. Wpad艂 na pomys艂, aby poprzez metalowy przew贸d zgromadzi膰 elektryczno艣膰 wytwarzan膮 przez obracaj膮c膮 si臋 szklan膮 tub臋 w wodzie przechowywanej w szklanym naczyniu. Szklane naczynie postawi艂 na materiale, kt贸ry mia艂 w艂a艣ciwo艣ci izolacyjne. Pewnego razu zapomnia艂 to zrobi膰 i trzyma艂 szklany pojemnik w d艂oni, i tak uda艂o mu si臋 zbudowa膰 pierwsze urz膮dzenie na 艣wiecie potrafi膮ce przechowywa膰 elektryczno艣膰. Nazwano je butelk膮 lejdejsk膮 i jest ona przodkiem element贸w elektrycznych znajduj膮cych si臋 dzi艣 w niemal ka偶dym urz膮dzeniu elektronicznym - to kondensator.
W 1800 roku, w艂oski fizyk Alessandro Volta zbudowa艂 pierwsz膮 baterie, zwan膮 stosem Volty. Warto podkre艣li膰, i偶 bateria ta generowa艂a energi臋 z elektrycznych w艂a艣ciwo艣ci dw贸ch r贸偶nych metali, bez udzia艂u jakiegokolwiek 藕r贸d艂a energii zewn臋trznej. Jego wk艂ad w elektryczno艣膰 by艂 tak wa偶ny, 偶e na jego cze艣膰 nazwano jednostk臋 napi臋cia jego nazwiskiem. Dziewi臋膰 lat p贸藕niej brytyjski chemik Humphry Davy zbudowa艂 najwi臋ksz膮 bateri臋 jak膮 do tej pory widziano i przed publiczno艣ci膮 zetkn膮 ze sob膮 dwa ko艅ce kabli pod艂膮czone do tej baterii generuj膮c po raz pierwszy elektryczne 艣wiat艂o wytworzone przez cz艂owieka, kt贸re zapowiada艂o nadej艣cie nowej ery w elektryczno艣ci.
Elektromagnetyzm
Michael Faraday by艂 angielskim samoukiem, kt贸ry interesowa艂 si臋 elektryczno艣ci膮. Uda艂o mu si臋 dosta膰 prac臋 na stanowisku asystent w laboratorium Royal Institution of Great Britain. W 1821 roku zbudowa艂 pierwsze urz膮dzenie, kt贸re jest przodkiem wszystkich obecnych silnik贸w elektrycznych. Odkry艂, 偶e pr膮d generuje pole magnetyczne, a jak wiadomo magnetyzm pozwala porusza膰 przedmioty. To odkrycie by艂o pocz膮tkiem nowej ery, w kt贸rej wa偶niejsze by艂o to, do czego pr膮d mo偶na wykorzysta膰, ni偶 czym w艂a艣ciwie jest. Faraday odkry艂 r贸wnie偶, 偶e proces ten mo偶na odwr贸ci膰. Ruch i magnetyzm m贸g艂 generowa膰 pr膮d. To w艂a艣nie na tej zasadzie dzia艂aj膮 dzisiejsze elektrownie, dzi臋ki kt贸rej teraz dzia艂a Tw贸j komputer. Faraday odkry艂 zjawisko zwane indukcj膮 elektromagnetyczn膮.
Mo偶na by si臋 domy艣le膰, 偶e kolejnym krokiem b臋dzie stworzenie elektrowni i 偶ar贸wki, jednak najpierw stworzono co艣 innego, co艣 co ma wi臋cej wsp贸lnego z komputerem ni偶 by si臋 mog艂o wydawa膰.
Telegraf
W 1827 roku Ameryka艅ski naukowiec Joseph Henry dopracowa艂 elektromagnes. Jego zasadnicz膮 cech膮 by艂o to, 偶e pole magnetyczne (elektromagnes) mo偶na by艂o kontrolowa膰 na odleg艂o艣膰 za pomoc膮 przewodu i pr膮du. To odkrycie pozwoli艂o na stworzenie pierwszego urz膮dzenia przydatnego w codziennym ludzkim 偶yciu, telegrafu.
 |
| Alfabet Morsa wikipedia.org |
W 1837 roku Samuel Morse zbudowa艂 pierwszy telegraf, kt贸ry wykorzystywa艂 prosty kod, zwany kodem Morsa. Zakodowanie alfabetu za pomoc膮 tylko dw贸ch odmiennych sygna艂贸w elektrycznych stanowi kamie艅 milowy dla 贸wczesnej informatyki.
Poni偶szy film demonstruje zasad臋 dzia艂ania telegrafu.
Poni偶szy film demonstruje zasad臋 dzia艂ania telegrafu.
Od 1850 roku pr贸bowano po艂膮czy膰 za pomoc膮 kabla 贸wczesne dwa mocarstwa, Angli臋 i Stany Zjednoczone. Pocz膮tkowo uwa偶ano, 偶e po艂o偶enie linii telegraficznej pod Atlantykiem jest niewykonywalne, jednak realne zyski zach臋ci艂y do pr贸b. Ostatecznie w 1859 roku na 艣rodku Atlantyku po艂膮czono ze sob膮 dwa kable, tym samym 艂膮cz膮c ze sob膮 i po raz pierwszy dwa kontynenty.
Niestety komunikaty by艂y ma艂o zrozumiane, odbiorca nie m贸g艂 odr贸偶ni膰 kr贸tkiego sygna艂u od d艂ugiego. Sytuacja okaza艂a si臋 frustruj膮ca. Jakby tego by艂o ma艂o in偶ynierowie postanowili zwi臋kszy膰 napi臋cie, gdy偶 uwa偶ali, 偶e wi臋ksze napi臋cie wygeneruje mocniejszy i wyra藕niejszy sygna艂. Niestety, konsekwencj膮 podniesienia napi臋cia by艂o zniszczenie kabla. Wtedy jeszcze nie do ko艅ca wiedziano nic o fali elektromagnetycznej i jak w艂a艣ciwie pr膮d p艂ynie przez przew贸d. Mimo wszystko po艂o偶enie transatlantyckiego kabla by艂o najwi臋kszym i najdro偶szym eksperymentem z elektryczno艣ci膮.
 |
| History of the Atlantic Cable |
W ko艅cu w 1866 roku po艂o偶ono nowy kabel, kt贸ry rozwi膮zywa艂 problem zak艂贸ce艅 poprzez zastosowanie ekranowania i ponownie przes艂ano wiadomo艣膰. Tym razem sygna艂 by艂 wyra藕ny i zrozumiany. Pierwszy raz informacja z Wielkiej Brytanii do Stan贸w Zjednoczonych dociera艂a niemal natychmiast zamiast dw贸ch tygodni. Osi膮gni臋cie to by艂o bardziej post臋pem cywilizacyjnym ni偶 technicznym.
Telefon
Nad ide膮 przesy艂ania g艂osu za pomoc膮 elektryczno艣膰 od 1875 roku pracowa艂 Alexander Graham Bell i to on z艂o偶y艂 pierwszy patent na telefon. Jednak to urz膮dzenie mia艂o wielu wsp贸艂tw贸rc贸w. W 1876 roku Alexander dokona艂 pierwszego udanego eksperymentu polegaj膮cego na przes艂aniu d藕wi臋ku: "Mr. Watson come here I want to see you". W kolejnych latach ca艂y czas udoskonalano t膮 technologi臋. Pierwsz膮 rozmow臋 d艂ugodystansow膮 pomi臋dzy Nowym Jorkiem a Kaliforni膮 wykonano dopiero a偶 w 1915 roku, ale jedna z pierwszych, a zarazem najbardziej znanych firm telekomunikacyjnych powsta艂a ju偶 w 1885 roku, to AT&T (American Telephone and Telegraph Company). AT&T odegra jedn膮 ze znacz膮cych r贸l w procesie powstawiania komputer贸w. Teraz ju偶 wiesz, sk膮d wzi臋艂a si臋 nazwa Bell Labs, nazwa laboratorium, w kt贸re mia艂o wielki wp艂yw na powstanie komputer贸w i system贸w operacyjnych.
W tym miejscu historia telefonu dopiero si臋 zaczyna, a kolejno艣膰 nast臋pnych odkry膰 traci liniowo艣膰. Wiele kolejnych odkry膰 by艂o dokonywanych r贸wnocze艣nie, a ich opracowanie i udoskonalanie trwa艂o lata. Postaram si臋 jednak zachowa膰 w艂a艣ciw膮 kolejno艣膰 dla nowych urz膮dze艅 wykorzystuj膮cych elektryczno艣膰.
艢wiat艂o
Jak pisa艂em w 1809 roku Humphry Davy po raz pierwszy wygenerowa艂 艣wiat艂o, w艂a艣ciwie by艂a to iskra i nie nadawa艂a si臋 do o艣wietlania dom贸w, poniewa偶 by艂a zbyt jasna. Pierwsza upowszechniona 偶ar贸wka pojawi艂a si臋 dopiero w 1880 roku, stworzy艂 j膮 Thomas Edison. Nowy rodzaj elektryczno艣ci zrewolucjonizowa艂 nasze 偶ycie. Do tej pory pomieszczenia o艣wietlano gazem, lampami naftowymi lub zwyk艂ymi 艣wiecami.
艢wiat艂o
 |
| wikipedia.org |
Dzi艣 trudno to sobie wyobrazi膰, ale wszystkich odkry膰 opisanych do tej pory dokonano w pewnym sensie przy 艣wietle 艣wiec. Mogli艣my wysy艂a膰 ju偶 telegramy, ale nadal u偶ywali艣my 艣wiec i nadal energia elektryczna nie by艂a powszechnie dost臋pna.
Dystrybucja energii elektrycznej
Cho膰 Edison nie by艂 jedynym wynalazc膮 偶ar贸wki, to ca艂a chwa艂a przypad艂a jemu. Jednak kluczem do elektrycznego biznesu by艂o generowanie pr膮du i jego dystrybucja do jak najwi臋kszej ilo艣ci odbiorc贸w. Tylko wtedy w pe艂ni mo偶na by艂o zarobi膰 na elektryczno艣ci. W tym momencie historia elektryczno艣ci przestaje mie膰 charakter czysto odkrywczy i nabiera czysto ekonomicznych cech.
W 1882 roku Edison w otoczeniu reporter贸w i bankier贸w zapowiedzia艂 wybudowanie pierwszej elektrowni (ang. power station) na Manhatanie. Stacja zosta艂a uruchomiona w 1890 roku i generowa艂a pr膮d sta艂y (DC). Jednak op艂acalno艣膰 takiego systemu by艂a zerowa, poniewa偶 mog艂a ona dostarcza膰 energi臋 tylko w obr臋bie jednej mili, z powodu strat napi臋cia. System ten by艂 bardzo ograniczony i drogi, a wielka wizja Edisona, w kt贸rej o艣wietli on ca艂y Nowy Jork zosta艂a powstrzymana przez ograniczenia jego systemu.
Wybudowanie elektrowni by艂o wielkim krokiem, pierwszy raz energi臋 mo偶na by艂o kupi膰. Poza tym centralne generowanie pozwala艂o uzyska膰 wi臋ksz膮 efektywno艣ci i ci膮g艂膮 prac臋. Jednak problemy z systemem rozprowadzania energii nie pozwala艂y na ekspansje elektryczno艣ci.
AC vs. DC
Rozwi膮zanie problemu zaproponowa艂 nieznany geniusz, by艂 nim Nikola Tesla. Zaproponowa艂 zupe艂nie inne rozwi膮zanie, by艂o nim generowanie pr膮du przemiennego (AC) poza miastami i dostarczanie do miasta. Tesla nie skupia艂 si臋 tylko na generowaniu pr膮du, opracowa艂 ca艂y system jego dystrybucji. Zalet膮 pr膮du przemiennego jest to, 偶e mo偶na go przesy艂a膰 bez znacznych strat na bardzo du偶e odleg艂o艣ci. Jego wad膮 by艂o to, 偶e wysokie napi臋cia pr膮du przemiennego s膮 niebezpieczne.
Jednak sam Tesla nie by艂 znany, ale jego patentem na generowanie pr膮du przemiennego i jego przetwarzanie na pr膮d sta艂y zainteresowa艂 si臋 George Westinghouse. Odkupi艂 go od Tesla za znaczn膮 kwot臋, oraz za sta艂膮 op艂at臋 od okre艣lonej ilo艣ci sprzedanej energii.
 |
| War of Currents - Transformator Tesli wikipedia.org |
W odpowiedzi na zab贸jcze dzia艂anie pr膮du przemiennego Tesla r贸wnie偶 przygotowa艂 pokaz, kt贸ry sprawi艂 i偶 ludzie uwierzyli, 偶e pr膮d przemienny o bardzo du偶ych napi臋ciach mo偶e by膰 bezpieczny. Pokaz Nikola Tesla z 1891 roku zmieni艂 bieg historii. W 1896 roku na wodospadzie Niagara zbudowano pierwsz膮 elektrowni臋, kt贸ra par臋 lat p贸藕niej zasili艂a Nowy Jork w energi臋 elektryczn膮. Dzi艣 wszyscy korzystamy z energii elektrycznej dostarczanej systemem Nikola Tesla. Teraz ju偶 wiesz dlatego do komputera potrzebny jest adapter DC.
Jednak historia Nikola Tesla nie ko艅czy si臋 w chwale i bogactwie. Cz艂owiek, kt贸ry pom贸g艂 stworzy膰 dzisiejszy 艣wiat umar艂 biedny i samotny w hotelowym pokoju, a Edison sta艂 si臋 w pewnym sensie bohaterem Ameryki.
 |
| Manhattan noc膮 zasilany systemem Tesli wikipedia.org |
 |
| NASA - Electromagnetic Spectrum |
Michael Faraday w 1846 roku powiedzia艂, i偶 艣wiat艂o to jedna z form fali elektromagnetycznych. Publiczno艣膰 go wy艣mia艂a, mimo i偶 by艂 ju偶 wtedy cenionym profesorem. Faraday nie potrafi艂 udowodni膰 swego twierdzenia, potrzebowa艂 kogo艣 kto by mu pom贸g艂. Po pi臋tnastu latach (1861 r.) profesor James Clerk Maxwell natkn膮艂 si臋 na ide臋 Faradaja i uwierzy艂 w ni膮. Postanowi艂 udowodni膰 to matematycznie.
W 1887 roku Heinrich Rudolf Hertz przeprowadzi艂 eksperymenty, kt贸re potwierdzi艂y prawid艂owo艣膰 oblicze艅 wykonanych przez Maxwell'a. W 1894 roku Oliver Lodge po raz pierwszy zaprezentowa艂 urz膮dzenie wykrywaj膮ce fale elektromagnetyczne. Wydarzenie to rozpoczyna now膮 er臋 w komunikacji i nauce.
Radio
Nie trudno domy艣li膰 si臋 co by艂o nast臋pstwem odkrycia fal elektromagnetycznych. Guglielmo Marconi jest najbardziej znanym nazwiskiem z wynalezienia radia. Co prawda nie tylko on rozwija艂 t膮 technologi臋 ale to jemu uda艂o si臋 pierwszemu dokona膰 transmisji przez Atlantyk. Jego pierwsze eksperymenty z radiem mia艂y miejsce w 1895 roku, natomiast pierwsza transatlantycka wiadomo艣膰 przez Marconiego mia艂a miejsce w 1902 roku.
Telewizor
Skoro to co widzimy jest 艣wiat艂em, a 艣wiat艂o jest fal膮 elektromagnetyczn膮, kt贸rymi zaczynano manipulowa膰, to mo偶liwe jest rejestrowanie i przesy艂anie obrazu do odbiornika. Tak jak w przypadku telefonu u偶yto greckiego s艂owa "tele", kt贸re oznacza na odleg艂o艣膰. Idea przesy艂ania obrazu na odleg艂o艣膰 powsta艂a mniej wi臋cej w tym samym czasie co przesy艂anie d藕wi臋ku.
Pierwsze urz膮dzenie potrafi膮ce odbiera膰 obraz stworzono w 1906 roku, jednak nie przypomina艂o ono nowoczesnych telewizor贸w kineskopowych. Du偶膮 rol臋 w rozwoju telewizji odegra艂y lampy elektronowe, z kt贸rych w przysz艂o艣ci budowano pierwsze komputery. Pierwsze stacje nadawcze, kt贸re s膮 dzi艣 jednymi z najwi臋kszych na 艣wiecie powstawa艂y na pocz膮tku lat trzydziestych, ale pierwszy przekaz kolorowego obrazu mia艂 miejsce w 1938 roku.
Tranzystor
W 1947 roku w Bell Labs stworzono pierwszy tranzystor. Tranzystor korzysta z fizycznych w艂a艣ciwo艣ci krzemu, kt贸re nazwano p贸艂przewodnikiem. Zasad臋 tranzystora mo偶na opisa膰 nast臋puj膮co. Wyobra藕 sobie, 偶e kawa艂ek p贸艂przewodnika (np. krzemu) 艂膮czy dwa przewody. Za艂贸偶my, 偶e pr膮d nie przep艂ywa przez p贸艂przewodnik. Teraz do krzemu przy艂膮czmy trzeci przew贸d odgrywaj膮cy rol臋 kontrolera. Za pomoc膮 kontrolera ma艂ym napi臋ciem uruchamiamy przewodnictwo wi臋kszych napi臋膰, czyli pozosta艂ych dw贸ch przewod贸w po艂膮czonych z krzemem. Mo偶na to por贸wna膰 do w艂膮cznika 艣wiat艂a, gdzie przycisk pe艂ni rol臋 kontrolera.
Zbudowanie elektronicznego prze艂膮cznika pozwoli艂o skonstruowa膰 logiczne bramki. Np. przy pomocy kilku tranzystor贸w mo偶na zbudowa膰 uk艂ady realizuj膮ce operacje logiczne, takiej jak AND, OR i NOT. Te proste operacje logiczne wraz z arytmetyk膮 binarn膮 s膮 podstawami dzisiejszych procesor贸w. Stworzenie tranzystora rozpoczyna er臋 贸wczesnych komputer贸w oraz ca艂膮 mas臋 urz膮dze艅 elektronicznych.
W 1948 roku Bell Labs opublikowa艂 jeden z najwa偶niejszych dokument贸w dla dzisiejszej komunikacji w sieci. "A Mathematical Theory of Communication", to matematyczne podstawy kodowania informacji przy pomocy urz膮dze艅 elektronicznych.
W 1956 roku John Bardeen, Walter H. Brattain i William Shockley otrzymali nagrod臋 Nobla z fizyki za wk艂ad w stworzenie tranzystora.
Dolina Krzemowa
Zapewne Dolina Krzemowa kojarzy Ci si臋 z informatyczn膮 mekk膮, Google, Facebook, Intel, Microsoft i ca艂膮 reszta wielkich korporacji. Jednak zanim tak si臋 sta艂o miejsce to mia艂o przeznaczenie rolnicze i by艂o pe艂ne owocowych sad贸w.
W 1953 jedne z konstruktor贸w tranzystora William Shockley opu艣ci艂 Bell Labs i za艂o偶y艂 firm臋 produkuj膮c膮 tranzystory zwan膮 Shockley Semiconductor Laboratory. Oczywi艣cie na lokalizacje wybra艂 wspomniane tereny rolnicze. Kolejn膮 oczywisto艣ci膮 jest to, 偶e sam nie m贸g艂 zaj膮膰 si臋 wszystkim, potrzebowa艂 wsp贸艂pracownik贸w. Tak wi臋c zebra艂 najlepszych fizyk贸w, by艂 tam chyba te偶 chemik i matematyk, razem by艂o ich o艣miu (zdradziecka 贸semka).
Je偶eli jeste艣 dociekliwy, pewnie zadajesz sobie pytanie dlaczego zdradziecka? Ot贸偶 osoby te mia艂y okazje pracowa膰 w pierwszej firmie zajmuj膮cej si臋 produkcj膮 p贸艂przewodnik贸w i zdoby艂y tam cenne do艣wiadczenia zawodowe. W tamtych czasach produkcj臋 p贸艂przewodnik贸w nap臋dza艂a zimna wojna, Shockley Semiconductor Laboratory realizowa艂 wiele zlece艅 dla Armii US. W ka偶dym b膮d藕 razie w 1957 roku ca艂a 贸semka opu艣ci艂a dotychczasowego pracodawc臋 i za艂o偶y艂a now膮 firm臋 zwan膮 Fairchild Semiconductor. W 1968 roku dw贸ch in偶ynier贸w ze wspomnianej 贸semki stworzy艂o kolejn膮 firm臋, kt贸r膮 na pewno kojarzysz. Robert Noyce i Gordon Moore stworzyli firm臋 Intel i tak powsta艂a Dolina Krzemowa.
W tym miejscu ko艅czy si臋 historia, kt贸r膮 chcia艂em przedstawi膰 a zaczyna si臋 historia wsp贸艂czesnej informatyki.
Podsumowanie
Ot贸偶 ka偶da cz臋艣膰 Twojego laptopa, czy tabletu ma swoich przodk贸w w przedstawionej historii. Ekran, dysk, WiFi, g艂adzik, zasilacz, bateria, g艂o艣niki, kamera, mikrofon, procesor, jednym s艂owem wszystko. Wszystko to sk艂ada si臋 na obecnie jedno z najbardziej z艂o偶onych urz膮dze艅 elektronicznych zwanych komputerem. Ka偶da z tych cz臋艣ci mo偶e dzia艂a膰 tylko dzi臋ki energii elektrycznej. Obecne komputery nie mog艂yby oferowa膰 takiej funkcjonalno艣ci, gdyby wcze艣niej nie wynaleziono 偶ar贸wki, elektrowni, baterii, telefonu, radia, telewizji i w ko艅cu tranzystora. Ka偶dy z tych wynalazk贸w jest cz臋艣ci膮 historii obecnych komputer贸w.
Wi臋c, je偶eli zastanawiasz si臋 jak dzia艂a WiFi, czy procesor, a tym bardziej jakich innowacji niebawem si臋 doczekasz, to w pewnym sensie pytasz o przysz艂o艣膰 urz膮dze艅 elektronicznych, z kt贸rych zbudowany jest Tw贸j komputer.
Ale tryumf elektryczno艣膰 nie ogranicza si臋 do zbudowania komputera przez cz艂owieka. Elektryczno艣膰, a w艂a艣ciwie nasza umiej臋tno艣膰 manipulowania ni膮 zmieni艂a ca艂y nasz dotychczasowy 艣wiat, komputer za艣 jest tylko jedna z form tej rewolucji.
 |
| NASA - EARTH'S CITY LIGHTS |
Wednesday, May 22, 2013
Czym SELinux nie jest
Prezentuje kolejne wideo o SELinux, tym razem staram si臋 odpowiedzie膰 na pytanie czym SELinux nie jest, czyli przed jakiego typu zagro偶eniami nas nie broni.
Jest to tak samo wa偶ne jak to, przed jakimi zagro偶eniami SELinux nas chroni.
Przedstawiam jak mog膮 dzia艂a膰 domeny SELinux, oraz jak SELinux ma si臋 do takich technik jak buffer overflow i shellcode. Je偶eli rozwa偶asz wdro偶enie SELinux i zastanawiasz si臋 przed czym rzeczywi艣cie ochroni on Tw贸j system, to poni偶sze wideo jest w艂a艣nie dla Ciebie.
Sunday, May 12, 2013
Standardowe uprawnienia a SELinux (MAC vs. DAC)
Po raz pierwszy na swoim blogu publikuje nagranie, mam nadziej臋 偶e b臋dzie u偶yteczne dla wielu os贸b. Niekt贸re tematy lepiej jest pokaza膰 ni偶 opisa膰, dlatego postanowi艂em zrobi膰 nagranie.
Temat "MAC vs. DAC" w kontek艣cie SELinux jest bardzo popularny, ba zazwyczaj rozpoczyna niemal ka偶dy dokument, ksi膮偶k臋 czy prezentacj臋 na temat SELinux. Jest to szczeg贸lny temat, bo wyja艣nia czym w艂a艣ciwie jest SELinux i czym r贸偶ni si臋 od tego czego u偶ywamy, czyli standardowych uprawnie艅 systemu. Z nagrania dowiesz si臋 czym w艂a艣ciwie jest SELinux.
Nazwa Security-Enhanced Linux podpowiada, 偶e chodzi o wzmocnione bezpiecze艅stwo, ale nazwa modelu, kt贸ry on implementuje (Mandatory Access Control) nie wiele wyja艣nia. W tym wideo wyja艣niam o co dok艂adnie chodzi w SELinux poprzez om贸wienie poni偶sze punkt贸w:
1. R贸偶nice pomi臋dzy MAC (Mandatory Access Control) a DAC (Discretionary Access Control)
2. Security-Enhanced Linux, co to dok艂adnie znaczy "wzmocniona/ulepszona"?
3. Dlaczego rozszerzony mechanizm kontroli sprawdzany jest po akceptacji standardowych uprawnie艅?
Sunday, March 3, 2013
LLVM i Linux
Ostatnio du偶o s艂ycha膰 o nowo艣ciach wprowadzanych w Linuksie, g艂ownie w j膮drze. Jednak jest pewna nowo艣膰, kt贸ra wprowadzi fundamentalne zmiany w kodzie ca艂ego systemu, ale dla u偶ytkownik贸w b臋dzie prawie niewidoczna - przynajmniej nie w swojej naturalnej postaci. Pr臋dzej czy p贸藕niej na pewno zaowocuje to ulepszeniami i nowo艣ciami, w niekt贸rych obszarach ju偶 tak si臋 sta艂o ale po kolei. W tym tek艣cie postaram si臋 przedstawi膰 projekt LLVM i Clang, wyja艣ni膰 czym s膮, jak dzia艂aj膮 i dlaczego s膮 lepsze od GCC, czyli tego czego obecnie u偶ywa GNU/Linux.
W informatyce wszystko zacz臋艂o si臋 od programowania, systemy operacyjne, aplikacje, a nawet same j臋zyki programowania. Jak to m贸wi膮 niekt贸rzy, w programowaniu pr臋dko艣ci膮 艣wiat艂a jest C - jakkolwiek by to nie zabrzmia艂o, to tak czy inaczej jest to prawd膮 E=mc2.
Systemy operacyjne i oprogramowanie wymagaj膮ce szybko艣ci dzia艂ania pisze si臋 w C lub C++. Z czasem, gdy komputery stawa艂y si臋 coraz szybsze zacz臋to przedk艂ada膰 prostot臋 i szybko艣膰 programowania nad wydajno艣膰. Nie przejmowano si臋 tym poniewa偶 ci膮g艂y wzrost mocy obliczeniowej obecnych komputer贸w to rekompensowa艂. Wtedy zacz臋艂y powstawa膰 nowe odmiany j臋zyk贸w programowania w sensie procesu przetwarzania kodu 藕r贸d艂owego na maszynowy. Odchodzono od kodu kompilowanego na rzecz wirtualnych maszyn i interpreter贸w. Wirtualne maszyny Javy VM i .NET-tu odnios艂y ogromny sukces. W przypadku Javy najwi臋kszym zyskiem by艂a przeno艣no艣膰 napisanych program贸w, koncepcja kodu po艣redniego w postaci wirtualnej maszyny sprawdzi艂a si臋 i udowodni艂a swoj膮 s艂uszno艣膰.
Drug膮 bardzo popularn膮 ga艂臋zi膮 i wcale nie now膮 by艂y j臋zyki interpretowane: PHP, Python i ca艂a masa innych. J臋zyk C i C++, zw艂aszcza ten drugi nadal si臋 rozwija艂, ale koncepcja generowania kodu nie zmieni艂a si臋 od lat. Zwolennicy wirtualnych maszyn chwalili sobie korzy艣ci jakie niesie ich u偶ywanie, a u偶ytkownicy j臋zyk贸w skryptowych chwalili sobie szybko艣膰 i prostot臋 pisania w tych j臋zykach. Czy to znaczy, 偶e racja musi le偶e膰 po jednej stronie, nie! Wojna pomi臋dzy zwolennikami j臋zyk贸w statycznych i dynamicznych zawsze trwa艂a, a w tym czasie kto艣 wpad艂 na genialny pomys艂 aby najlepszy j臋zyk na 艣wiecie wyposa偶y膰 w rozwi膮zanie hybrydowe. Okazuje si臋, 偶e lepszym wyborem jest po艂膮czenie dw贸ch metod ni偶 wybieranie jednej z nich. Co ciekawe, koncepcja po艂膮czenia kompilacji statycznej z dynamiczn膮 w C/C++ nie powsta艂a wczoraj, ale w 2000 roku w projekcie LLVM.
Pe艂na nazwa projektu brzmi Low Level Virtual Machine, ale nie do ko艅ca oddaje ona czym obecnie jest projekt LLVM. Przede wszystkim utworzenie wirtualnej maszyny dla kodu generowanego przez C/C++ nie by艂o jednym celem projektu. Chciano przy okazji wzbogaci膰 kompilator o nowe mo偶liwo艣ci, kt贸rych brakowa艂o do tej pory g艂贸wnie dla GCC. LLVM to grupa kilku podprojekt贸w tworz膮cych kolekcj臋 narz臋dzi u艂atwiaj膮cych i optymalizuj膮cych proces tworzenia kodu. Modularna budowa umo偶liwia wygodny rozw贸j i widocznie gwarantuje sukces. Zanim jednak podam przyk艂ady obecnych osi膮gni臋膰 LLVM chcia艂bym zwr贸ci膰 uwag臋 na co艣 co jest sercem ka偶dej maszyny wirtualnej - to jej "Bitcode".
Tradycyjny kompilator j臋zyka C/C++, taki jak GCC wykonuje trzy podstawowe etapy:
Zwr贸膰 uwag臋, 偶e od samego pocz膮tku do ko艅ca kompilator pos艂uguje si臋 kodem maszynowym przeznaczonym dla konkretnej architektury. Ponad to wirtualna maszyna LLVM nie zajmuje si臋 pierwszym etapem, tym zajmuje si臋 inny projekt zwany Clang, o kt贸rym napisz臋 w dalszej cz臋艣ci tekstu.
W celu lepszej prezentacji architektury LLVM oraz zrozumienia jakie zadania realizuj膮 poszczeg贸lne podprojekty stworzy艂em poni偶szy schemat. Prezentuje on przep艂yw kodu 藕r贸d艂owego, a偶 do kodu maszynowego i nie zawiera nawet wi臋kszo艣ci podprojekt贸w LLVM.
LLVM posiada tak zwane front-endy, s膮 to kompilatory. Ich zadaniem jest dostarczenie kodu dla wirtualnej maszyny w specyficznym formacje, nie maj膮cym jednak nic wsp贸lnego z kodem maszynowym przeznaczonym dla konkretnej architektury. Standardowo GCC nie potrafi generowa膰 bitcode dla LLVM, dlatego stworzono odmian臋 kompilatora zwan膮 llvm-gcc, obecnie jest to rozszerzenie dla samego GCC zwane DragonEgg. Jego zadanie polega na analizie kodu 藕r贸d艂owego zgodnie ze standardami GCC, ale generowany kod jest przeznaczony dla wirtualnej maszyny LLVM, a nie architektury procesora.
Drugim kompilatorem jest Clang, to w艂asny projekt LLVM stworzony od podstaw na jego potrzemy. To w艂a艣nie on jest jednym z powod贸w sukcesu LLVM i ch臋ci kompilacji Linuksa na LLVM.
Clang jest kompilatorem j臋zyka C, C++ i Objective C, kt贸ry jest kompatybilny z GCC. Oczywi艣cie jego kompatybilno艣膰 dotyczy g艂贸wnie sk艂adni a nie rozszerze艅, te drugie s膮 z kolei najwi臋kszym problemem w procesie kompilacji j膮dra Linux na Clang.
Najwi臋ksz膮 zalet膮 Clang s膮 jego rozbudowane i przyjazne dla cz艂owieka komunikaty o b艂臋dach, opr贸cz lepszego wskazywania b艂臋d贸w podpowiada jak je rozwi膮za膰. W praktyce oznacza to szybsze odnajdowanie b艂臋d贸w i ich napraw臋, czyli szybszy rozw贸j systemu. Wa偶ne jest to, 偶e cz臋sto Clang szybciej wykonuje kompilacj臋, zu偶ywa przy tym mniej zasob贸w, tworzy mniejszy i bardziej zoptymalizowany kod wykonywalny ni偶 GCC.
Jedn膮 z egzotycznych mo偶liwo艣ci Clang jest dynamiczna kompilacja JIT, tak jak ma to miejsce w przypadku np. Pythona - kompilowany kod jest od razu wykonywany na bie偶膮co.
Podobnie jak w LLVM budowa Clang jest modularna i Clang jest czym艣 wi臋cej ni偶 tylko kompilatorem - to kompilator z mo偶liwo艣ci膮 integrowania przydatnych narz臋dzi. Clang obs艂uguje wiele funkcji, kt贸re umo偶liwiaj膮 lepsza integracj臋 ze 艣rodowiskami IDE. Przyk艂adem takiego rozszerzenia jest source code refactoring (zobacz nagranie Clang MapReduce -- Automatic C++ Refactoring at Google Scale), kt贸ry umo偶liwia zmian臋 nazw np. metod konkretnej klasy. Drugim przyk艂adem mo偶e by膰 Clang Static Analyzer, kt贸ry pozwala na sprawdzenie b艂臋d贸w w kodzie bez kompilacji, niestety sama analiza nie jest szybsza ni偶 sama kompilacja, ale z kompilacj膮 by艂aby o wiele d艂u偶sza.
Nie trudno domy艣li膰 si臋 偶e Apple i Google s膮 firmami, kt贸re rozwijaj膮 LLVM ale s膮 te偶 inne g艂贸wnie Qualcomm Innovation Center i Intel oraz wiele instytucji naukowych i edukacyjnych. LLVM u偶ywaj膮 o艣rodki naukowe, takiej jak CERN i Argonne National Laboratory. LLVM/Clang u偶ywa nawet Adobe, wi臋cej przyk艂ad贸w mo偶esz znale藕膰 na stronie LLVM Users.
Czy wiesz, 偶e Linus Torvalds zacz膮艂 prac臋 nad j膮drem Linux, bo zafascynowa艂 si臋 systemem MINIX? Teraz domy艣lnym kompilatorem w MINIX jest Clang.
Obecnie przechodzi na niego FreeBSD, wszystko zacz臋艂o si臋 od tego, 偶e projekt nie m贸g艂 zaakceptowa膰 nowej licencji GPLv3 obowi膮zuj膮cej nowe wersie GCC. Szukaj膮c wyj艣cia z sytuacji postanowi艂 wybra膰 LLVM, podobnie by艂o z Apple.
Dotarli艣my do sedna tego tekstu, wygl膮da na to, 偶e po sukcesach jakie odni贸s艂 LLVM deweloperzy chc膮 umo偶liwi膰 kompilacj臋 j膮dra i ca艂ego systemu na Clang. Je偶eli chodzi o j膮dro to tym zajmuje si臋 projekt LLVMLinux (llvm.linuxfoundation.org), natomiast je偶eli mowa o pierwszej dystrybucji, kt贸ra zostanie skompilowana w ca艂o艣ci na Clang to najprawdopodobniej b臋dzie to Debian. Obecnie tylko 12% pakiet贸w nie uda艂o si臋 jeszcze skompilowanych przy pomocy Clang, stan tego procesu mo偶na 艣ledzi膰 przez stroni臋 clang.debian.net. Wprowadzeniem Clang do Debiana zajmuje si臋 Sylvestre Ledru, jak pisze, robi to po to, aby przekona膰 si臋 czy system GNU/Linux mo偶e skorzysta膰 na LLVM. Wi臋cej o procesie kompilacji Debiana dowiesz si臋 z prezentacji Make Debian compiler agnostic - Building Debian with LLVM/Clang na FOSDEM'13.
Par臋 dni temu odby艂a si臋 konferencja Embedded Linux Conference 2013, na kt贸rej Behan Webster prezentowa艂 obecny stan prac w procesie przystosowywania j膮dra do kompilacji na Clang. Pierwsza cz臋艣膰 prezentacji odpowiada na pytanie dlaczego kompilowa膰 j膮dro na Clang, druga cz臋艣膰 dotyczy technicznych problem贸w z tym zwi膮zanych.
Podczas spotkania LLVM Developer Meeting 2012 zaprezentowano jak bardzo przy艣piesza rozw贸j tego projektu. S膮dz膮c po liczbach, wspomnianych wy偶ej osi膮gni臋ciach i mo偶liwo艣ciach nie spos贸b oprze膰 si臋 wra偶eniu, 偶e LLVM i Clang w najbli偶szej przysz艂o艣ci mog膮 sta膰 si臋 standardem w projektach open source.
RenderScript, edu4android.com
W informatyce wszystko zacz臋艂o si臋 od programowania, systemy operacyjne, aplikacje, a nawet same j臋zyki programowania. Jak to m贸wi膮 niekt贸rzy, w programowaniu pr臋dko艣ci膮 艣wiat艂a jest C - jakkolwiek by to nie zabrzmia艂o, to tak czy inaczej jest to prawd膮 E=mc2.
Systemy operacyjne i oprogramowanie wymagaj膮ce szybko艣ci dzia艂ania pisze si臋 w C lub C++. Z czasem, gdy komputery stawa艂y si臋 coraz szybsze zacz臋to przedk艂ada膰 prostot臋 i szybko艣膰 programowania nad wydajno艣膰. Nie przejmowano si臋 tym poniewa偶 ci膮g艂y wzrost mocy obliczeniowej obecnych komputer贸w to rekompensowa艂. Wtedy zacz臋艂y powstawa膰 nowe odmiany j臋zyk贸w programowania w sensie procesu przetwarzania kodu 藕r贸d艂owego na maszynowy. Odchodzono od kodu kompilowanego na rzecz wirtualnych maszyn i interpreter贸w. Wirtualne maszyny Javy VM i .NET-tu odnios艂y ogromny sukces. W przypadku Javy najwi臋kszym zyskiem by艂a przeno艣no艣膰 napisanych program贸w, koncepcja kodu po艣redniego w postaci wirtualnej maszyny sprawdzi艂a si臋 i udowodni艂a swoj膮 s艂uszno艣膰.
Drug膮 bardzo popularn膮 ga艂臋zi膮 i wcale nie now膮 by艂y j臋zyki interpretowane: PHP, Python i ca艂a masa innych. J臋zyk C i C++, zw艂aszcza ten drugi nadal si臋 rozwija艂, ale koncepcja generowania kodu nie zmieni艂a si臋 od lat. Zwolennicy wirtualnych maszyn chwalili sobie korzy艣ci jakie niesie ich u偶ywanie, a u偶ytkownicy j臋zyk贸w skryptowych chwalili sobie szybko艣膰 i prostot臋 pisania w tych j臋zykach. Czy to znaczy, 偶e racja musi le偶e膰 po jednej stronie, nie! Wojna pomi臋dzy zwolennikami j臋zyk贸w statycznych i dynamicznych zawsze trwa艂a, a w tym czasie kto艣 wpad艂 na genialny pomys艂 aby najlepszy j臋zyk na 艣wiecie wyposa偶y膰 w rozwi膮zanie hybrydowe. Okazuje si臋, 偶e lepszym wyborem jest po艂膮czenie dw贸ch metod ni偶 wybieranie jednej z nich. Co ciekawe, koncepcja po艂膮czenia kompilacji statycznej z dynamiczn膮 w C/C++ nie powsta艂a wczoraj, ale w 2000 roku w projekcie LLVM.
LLVM
 |
| Logo projektu LLVM |
Tradycyjny kompilator j臋zyka C/C++, taki jak GCC wykonuje trzy podstawowe etapy:
- poddaje sk艂adni leksykalnej kod 藕r贸d艂owy
- generuje odpowiadaj膮cy instrukcjom j臋zyka kod maszynowy, do艂膮cza niezb臋dny kod u偶ywanych bibliotek i optymalizuje wszystko razem
- tworzy ostateczny format pliku wykonywalnego z kodem maszynowym
Zwr贸膰 uwag臋, 偶e od samego pocz膮tku do ko艅ca kompilator pos艂uguje si臋 kodem maszynowym przeznaczonym dla konkretnej architektury. Ponad to wirtualna maszyna LLVM nie zajmuje si臋 pierwszym etapem, tym zajmuje si臋 inny projekt zwany Clang, o kt贸rym napisz臋 w dalszej cz臋艣ci tekstu.
Architektura LLVM
 |
| Architektura LLVM |
Drugim kompilatorem jest Clang, to w艂asny projekt LLVM stworzony od podstaw na jego potrzemy. To w艂a艣nie on jest jednym z powod贸w sukcesu LLVM i ch臋ci kompilacji Linuksa na LLVM.
 |
| "LLVM - 2.0 and beyond!" Chris Lattner, Google Tech Talk July 27, 2007 |
Clang
Najwi臋ksz膮 zalet膮 Clang s膮 jego rozbudowane i przyjazne dla cz艂owieka komunikaty o b艂臋dach, opr贸cz lepszego wskazywania b艂臋d贸w podpowiada jak je rozwi膮za膰. W praktyce oznacza to szybsze odnajdowanie b艂臋d贸w i ich napraw臋, czyli szybszy rozw贸j systemu. Wa偶ne jest to, 偶e cz臋sto Clang szybciej wykonuje kompilacj臋, zu偶ywa przy tym mniej zasob贸w, tworzy mniejszy i bardziej zoptymalizowany kod wykonywalny ni偶 GCC.
 |
| "LLVM - 2.0 and beyond!" Chris Lattner, Google Tech Talk July 27, 2007 |
Podobnie jak w LLVM budowa Clang jest modularna i Clang jest czym艣 wi臋cej ni偶 tylko kompilatorem - to kompilator z mo偶liwo艣ci膮 integrowania przydatnych narz臋dzi. Clang obs艂uguje wiele funkcji, kt贸re umo偶liwiaj膮 lepsza integracj臋 ze 艣rodowiskami IDE. Przyk艂adem takiego rozszerzenia jest source code refactoring (zobacz nagranie Clang MapReduce -- Automatic C++ Refactoring at Google Scale), kt贸ry umo偶liwia zmian臋 nazw np. metod konkretnej klasy. Drugim przyk艂adem mo偶e by膰 Clang Static Analyzer, kt贸ry pozwala na sprawdzenie b艂臋d贸w w kodzie bez kompilacji, niestety sama analiza nie jest szybsza ni偶 sama kompilacja, ale z kompilacj膮 by艂aby o wiele d艂u偶sza.
LLVM Optimizer
 |
| "LLVM - 2.0 and beyond!" Chris Lattner, Google Tech Talk July 27, 2007 |
Mechanizm optymalizacyjny maszyny LLVM dzia艂a na w艂asnym formacie kodu, dzi臋ki temu niezale偶nie czy kod pochodzi z C, C++ czy innego j臋zyka poddawany jest tym samym mechanizmom optymalizacji, a p贸藕niej jest przet艂umaczany na kod maszynowy dla konkretnej architektury, czyli na tzw. back-end. To sprawia, 偶e programi艣ci do tej pory pracuj膮cy nad optymalizacj膮 r贸偶nych kompilator贸w teraz mog膮 wsp贸lnie pracowa膰 nad jednym projektem i na dodatek na przejmowa膰 si臋 specyfik膮 j臋zyka ani architektury.
Istot膮 bitcode jest niezale偶no艣膰 od j臋zyka i architektury, dlatego musi on by膰 w takiej formie, aby bez problemu mo偶na by艂o przet艂umaczy膰 ka偶d膮 instrukcj臋 z ka偶dego j臋zyka na niego oraz aby ka偶dy bitcode mo偶na by艂o potem przet艂umaczy膰 na dowoln膮 architektur臋. Tym pierwszym zajmuj膮 si臋 front-end, a drugim back-end.
LLVM Intermediate Representation (IR)
IR to format j臋zyka wirtualnej maszyny LLVM (jego low-level bitcode), co ciekawe dost臋pny jest ona w tekstowej postaci czytelnej dla cz艂owieka, co przynios艂o dla LLVM najwi臋kszy sukces. Dzi臋ki temu pisanie front-end贸w i back-end贸w jest bardzo proste w przeciwie艅stwie do GIMPLE z GCC.
Form膮, kt贸ra obs艂u偶y ka偶dy j臋zyk i ka偶d膮 architektur臋 okaza艂y si臋 kr贸tkie instrukcje o sta艂ej d艂ugo艣ci, jak w RISC. Opis tego kodu mo偶na zobaczy膰 na stronie projektu.
Z kolei na blogu LLVM zosta艂 opublikowany opis dok艂adnie wyja艣niaj膮cy cykl 偶ycia instrukcji w maszynie LLVM: Life of an instruction in LLVM.
Kto u偶ywa LLVM
Przede wszystkim Apple, LLVM jest podstaw膮 XCode. Apple wykorzystuj膮c modularno艣膰 LLVM (back-end) i mo偶liwo艣膰 kompilacji dynamicznej stworzy艂o OpenCL - framework, kt贸ry pozwala na pisanie kodu niezale偶nego od 艣rodowiska sprz臋towego. Jednym z przyk艂ad贸w jest mo偶liwo艣膰 wykonania graficznych operacji na sprz臋cie nie wyposa偶onym w GPU.
Kolejnym du偶ym u偶ytkownikiem jest Google, kt贸ry u偶ywa Clang dla swoich w艂asnych bibliotek i silnika wyszukiwa艅. Najbardziej jednak skorzysta艂 na tym Android, jego Renderscript jest podstaw膮 dzia艂ania aplikacji graficznych na przer贸偶nych tabletach i telefonach. Zastanawia艂e艣 si臋 kiedy艣 czym jest format .apk u偶ywany przez aplikacje 艣ci膮gane ze sklepu Google play? To bitcode LLVM, kt贸ry zosta艂 skompilowany na dowolnym urz膮dzeniu. Podczas pierwszego uruchomienia zostanie on przetworzony przez back-end z bitcode LLVM na architektur臋 twojego urz膮dzenia i po prostu dzia艂a.
Tak samo sprawa wygl膮da z aplikacjami w Chrome, sp贸jrz na projekt Portable Native Client (PNaCl).
Warto wspomnie膰 o GNOME Shell, kt贸ry emuluje efekty graficzne nawet na maszynach nie wspieraj膮cych akceleracji 3D, a to dzi臋ki LLVMpipe.
Nie trudno domy艣li膰 si臋 偶e Apple i Google s膮 firmami, kt贸re rozwijaj膮 LLVM ale s膮 te偶 inne g艂贸wnie Qualcomm Innovation Center i Intel oraz wiele instytucji naukowych i edukacyjnych. LLVM u偶ywaj膮 o艣rodki naukowe, takiej jak CERN i Argonne National Laboratory. LLVM/Clang u偶ywa nawet Adobe, wi臋cej przyk艂ad贸w mo偶esz znale藕膰 na stronie LLVM Users.
Kto przeszed艂 na LLVM
Obecnie przechodzi na niego FreeBSD, wszystko zacz臋艂o si臋 od tego, 偶e projekt nie m贸g艂 zaakceptowa膰 nowej licencji GPLv3 obowi膮zuj膮cej nowe wersie GCC. Szukaj膮c wyj艣cia z sytuacji postanowi艂 wybra膰 LLVM, podobnie by艂o z Apple.
Kto nie chcia艂by mie膰 pingwina ze skrzyd艂ami smoka?
 |
| LLVMLinux |
Par臋 dni temu odby艂a si臋 konferencja Embedded Linux Conference 2013, na kt贸rej Behan Webster prezentowa艂 obecny stan prac w procesie przystosowywania j膮dra do kompilacji na Clang. Pierwsza cz臋艣膰 prezentacji odpowiada na pytanie dlaczego kompilowa膰 j膮dro na Clang, druga cz臋艣膰 dotyczy technicznych problem贸w z tym zwi膮zanych.
Szybki rozw贸j
 |
| LLVM Developer Meeting 2012 San Jose, November 8, 2012 |
 |
| LLVM Developer Meeting 2012 San Jose, November 8, 2012 |
Co prawda nie brakuje r贸wnie偶 negatywnych ocen dla LLVM/Clang oraz w膮tpliwo艣ci zwi膮zanych z licencj膮 UIUC License (BSD-style). Wiele z tych kwestii jest poruszanych w artykule Distributions looking at LLVM na LWN.net.
Mimo wszystko uwa偶am, 偶e uczynienie systemu Linux kompatybilnym z LLVM/Clang jest jak najbardziej s艂uszne, zawsze zostaje jeszcze GCC. Wierz臋, 偶e w open source, tak jak w biologii r贸偶norodno艣膰 zwi臋ksza szanse przetrwania gatunku. Mo偶liwo艣膰 kompilacji systemu Linux na dw贸ch r贸偶nych kompilatorach mo偶e mu tylko pom贸c, a nie zaszkodzi膰.
Pozosta艂e zasoby:
Mimo wszystko uwa偶am, 偶e uczynienie systemu Linux kompatybilnym z LLVM/Clang jest jak najbardziej s艂uszne, zawsze zostaje jeszcze GCC. Wierz臋, 偶e w open source, tak jak w biologii r贸偶norodno艣膰 zwi臋ksza szanse przetrwania gatunku. Mo偶liwo艣膰 kompilacji systemu Linux na dw贸ch r贸偶nych kompilatorach mo偶e mu tylko pom贸c, a nie zaszkodzi膰.
Pozosta艂e zasoby:
"LFCS 2012: LLVM and Linux", lwn.net
"Mac OS X 10.5 Leopard: the Ars Technica review", arstechnica.com
"Mac OS X 10.6 Snow Leopard: the Ars Technica review", arstechnica.com
"Fedora 16 is gold, but more importantly…", www.happyassassin.net
"GNOME Shell Now Works With Software Rendering!", www.phoronix.com
"LLVM", The Architecture of Open Source Applications
Subscribe to:
Posts (Atom)