Re: [so] [Tema3][General] Protectie pagina ce trebuie zeroizata
Din nou, MAP_ANONYMOUS îți face memset(0) direct în kernel pentru că nu ești pe Arduino sau altă platformă pe care să fie dezactivată această funcție de securitate. Deci primești din prima cu 0, așa că nu înțeleg întrebarea. Sent from Mail for Windows 10 From: Dorin Geman via soSent: Friday, April 3, 2020 9:37 PMTo: Darius Mihai; Sisteme de OperareSubject: Re: [so] [Tema3][General] Protectie pagina ce trebuie zeroizata On Fri, Apr 3, 2020 at 9:05 PM Darius Mihai <dariusmih...@gmail.com> wrote:On Fri, Apr 3, 2020 at 8:50 PM Dorin Geman via so <so@cursuri.cs.pub.ro> wrote:>> Salutare,>> Am o curiozitate(prioritate scăzută) - mi se pare că testele nu verifică un anumit caz, probabil pentru că este greu de simulat, dar cel puțin conceptual, vă întreb:>> Corect este că dacă trebuie să zeroiezez o zonă de memorie, mai întăi să mapez pagina cu WRITE pentru a putea zeroiza și apoi să îi schimb permisiunile în cele corespunzătoare segmentului din care face parte, de acord?> Cu toate acestea, dacă mapez de la început cu permisiunile segmentului, totul este în regulă, trec testele, pentru că se testează doar pentru zona de bss.> Exemplul care ar face cea din urmă implementare să "pice" ar fi ca în executabilul pe care vreau să îl încarc să am un mmap cu READ și ANONYMOUS? Alte idei de scenarii?>> Pentru asistenții indicați pe ocw[0] , puteți vedea codul pt GitLab[1] - liniile 65-85.> Dacă mapez din prima cu segment.perm și scot mprotect, all good, dar nu mi se pare tocmai corect.>> Numai bine,> Dorin Geman, 331CA>> [0] https://ocw.cs.pub.ro/courses/so/teme/folosire-gitlab#creare_proiect_nou> [1] https://gitlab.cs.pub.ro/dorin_andrei.geman/l3-so-assignments/blob/master/3-loader/skel-lin/loader/loader.cSalut, Dorin,Din motive de securitate (nu vrei ca un proces să poată accesa dateledin memoria fizică pe care un alt proces a eliberat-o), mapareazonelor de memorie în mod anonim va zeroiza pagina înainte ca tu poțisă o accesezi. Vezi și în pagina de manual [3], la secțiuneaMAP_ANONYMOUS. Acest comportament ar putea, în teorie, să nu fieactiv pe unele sisteme vechi sau embedded (din motive de performanță),dar este aproape sigur prezent pe sistemele uzual folosite de acum.[3]: https://linux.die.net/man/2/mmapO seară frumoasă,Darius Salut, Darius! Corect, am înțeles.Atunci cum pot simula un scenariu în care sa pice codul meu de loader dacă nu dau PROT_WRITE explicit înainte de zeroizare?Mai concret, dacă trebuie să mapez o pagină read-only si trebuie să îi ofer și drept de scriere până termin zeroizarea, dar nu i-l ofer. Seară faină,Dorin ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][General] Protectie pagina ce trebuie zeroizata
Din nou, MAP_ANONYMOUS îți face memset(0) direct în kernel pentru că nu ești pe Arduino sau altă platformă pe care să fie dezactivată această funcție de securitate. Deci primești din prima cu 0, așa că nu înțeleg întrebarea. Sent from Mail for Windows 10 From: Dorin Geman via soSent: Friday, April 3, 2020 9:37 PMTo: Darius Mihai; Sisteme de OperareSubject: Re: [so] [Tema3][General] Protectie pagina ce trebuie zeroizata On Fri, Apr 3, 2020 at 9:05 PM Darius Mihai <dariusmih...@gmail.com> wrote:On Fri, Apr 3, 2020 at 8:50 PM Dorin Geman via so <so@cursuri.cs.pub.ro> wrote:>> Salutare,>> Am o curiozitate(prioritate scăzută) - mi se pare că testele nu verifică un anumit caz, probabil pentru că este greu de simulat, dar cel puțin conceptual, vă întreb:>> Corect este că dacă trebuie să zeroiezez o zonă de memorie, mai întăi să mapez pagina cu WRITE pentru a putea zeroiza și apoi să îi schimb permisiunile în cele corespunzătoare segmentului din care face parte, de acord?> Cu toate acestea, dacă mapez de la început cu permisiunile segmentului, totul este în regulă, trec testele, pentru că se testează doar pentru zona de bss.> Exemplul care ar face cea din urmă implementare să "pice" ar fi ca în executabilul pe care vreau să îl încarc să am un mmap cu READ și ANONYMOUS? Alte idei de scenarii?>> Pentru asistenții indicați pe ocw[0] , puteți vedea codul pt GitLab[1] - liniile 65-85.> Dacă mapez din prima cu segment.perm și scot mprotect, all good, dar nu mi se pare tocmai corect.>> Numai bine,> Dorin Geman, 331CA>> [0] https://ocw.cs.pub.ro/courses/so/teme/folosire-gitlab#creare_proiect_nou> [1] https://gitlab.cs.pub.ro/dorin_andrei.geman/l3-so-assignments/blob/master/3-loader/skel-lin/loader/loader.cSalut, Dorin,Din motive de securitate (nu vrei ca un proces să poată accesa dateledin memoria fizică pe care un alt proces a eliberat-o), mapareazonelor de memorie în mod anonim va zeroiza pagina înainte ca tu poțisă o accesezi. Vezi și în pagina de manual [3], la secțiuneaMAP_ANONYMOUS. Acest comportament ar putea, în teorie, să nu fieactiv pe unele sisteme vechi sau embedded (din motive de performanță),dar este aproape sigur prezent pe sistemele uzual folosite de acum.[3]: https://linux.die.net/man/2/mmapO seară frumoasă,Darius Salut, Darius! Corect, am înțeles.Atunci cum pot simula un scenariu în care sa pice codul meu de loader dacă nu dau PROT_WRITE explicit înainte de zeroizare?Mai concret, dacă trebuie să mapez o pagină read-only si trebuie să îi ofer și drept de scriere până termin zeroizarea, dar nu i-l ofer. Seară faină,Dorin ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][General] Protectie pagina ce trebuie zeroizata
On Fri, Apr 3, 2020 at 9:05 PM Darius Mihai wrote: > On Fri, Apr 3, 2020 at 8:50 PM Dorin Geman via so > wrote: > > > > Salutare, > > > > Am o curiozitate(prioritate scăzută) - mi se pare că testele nu verifică > un anumit caz, probabil pentru că este greu de simulat, dar cel puțin > conceptual, vă întreb: > > > > Corect este că dacă trebuie să zeroiezez o zonă de memorie, mai întăi să > mapez pagina cu WRITE pentru a putea zeroiza și apoi să îi schimb > permisiunile în cele corespunzătoare segmentului din care face parte, de > acord? > > Cu toate acestea, dacă mapez de la început cu permisiunile segmentului, > totul este în regulă, trec testele, pentru că se testează doar pentru zona > de bss. > > Exemplul care ar face cea din urmă implementare să "pice" ar fi ca în > executabilul pe care vreau să îl încarc să am un mmap cu READ și ANONYMOUS? > Alte idei de scenarii? > > > > Pentru asistenții indicați pe ocw[0] , puteți vedea codul pt GitLab[1] - > liniile 65-85. > > Dacă mapez din prima cu segment.perm și scot mprotect, all good, dar nu > mi se pare tocmai corect. > > > > Numai bine, > > Dorin Geman, 331CA > > > > [0] > https://ocw.cs.pub.ro/courses/so/teme/folosire-gitlab#creare_proiect_nou > > [1] > https://gitlab.cs.pub.ro/dorin_andrei.geman/l3-so-assignments/blob/master/3-loader/skel-lin/loader/loader.c > > Salut, Dorin, > > Din motive de securitate (nu vrei ca un proces să poată accesa datele > din memoria fizică pe care un alt proces a eliberat-o), maparea > zonelor de memorie în mod anonim va zeroiza pagina înainte ca tu poți > să o accesezi. Vezi și în pagina de manual [3], la secțiunea > MAP_ANONYMOUS. Acest comportament ar putea, în teorie, să nu fie > activ pe unele sisteme vechi sau embedded (din motive de performanță), > dar este aproape sigur prezent pe sistemele uzual folosite de acum. > > [3]: https://linux.die.net/man/2/mmap > > O seară frumoasă, > Darius > Salut, Darius! Corect, am înțeles. Atunci cum pot simula un scenariu în care sa pice codul meu de loader dacă nu dau PROT_WRITE explicit înainte de zeroizare? Mai concret, dacă trebuie să mapez o pagină read-only si trebuie să îi ofer și drept de scriere până termin zeroizarea, dar nu i-l ofer. Seară faină, Dorin ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][General] Protectie pagina ce trebuie zeroizata
On Fri, Apr 3, 2020 at 8:50 PM Dorin Geman via so wrote: > > Salutare, > > Am o curiozitate(prioritate scăzută) - mi se pare că testele nu verifică un > anumit caz, probabil pentru că este greu de simulat, dar cel puțin > conceptual, vă întreb: > > Corect este că dacă trebuie să zeroiezez o zonă de memorie, mai întăi să > mapez pagina cu WRITE pentru a putea zeroiza și apoi să îi schimb > permisiunile în cele corespunzătoare segmentului din care face parte, de > acord? > Cu toate acestea, dacă mapez de la început cu permisiunile segmentului, totul > este în regulă, trec testele, pentru că se testează doar pentru zona de bss. > Exemplul care ar face cea din urmă implementare să "pice" ar fi ca în > executabilul pe care vreau să îl încarc să am un mmap cu READ și ANONYMOUS? > Alte idei de scenarii? > > Pentru asistenții indicați pe ocw[0] , puteți vedea codul pt GitLab[1] - > liniile 65-85. > Dacă mapez din prima cu segment.perm și scot mprotect, all good, dar nu mi se > pare tocmai corect. > > Numai bine, > Dorin Geman, 331CA > > [0] https://ocw.cs.pub.ro/courses/so/teme/folosire-gitlab#creare_proiect_nou > [1] > https://gitlab.cs.pub.ro/dorin_andrei.geman/l3-so-assignments/blob/master/3-loader/skel-lin/loader/loader.c Salut, Dorin, Din motive de securitate (nu vrei ca un proces să poată accesa datele din memoria fizică pe care un alt proces a eliberat-o), maparea zonelor de memorie în mod anonim va zeroiza pagina înainte ca tu poți să o accesezi. Vezi și în pagina de manual [3], la secțiunea MAP_ANONYMOUS. Acest comportament ar putea, în teorie, să nu fie activ pe unele sisteme vechi sau embedded (din motive de performanță), dar este aproape sigur prezent pe sistemele uzual folosite de acum. [3]: https://linux.die.net/man/2/mmap O seară frumoasă, Darius ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][General]
Salut, Da. Este ok Cu stimÄ,Mihai BÄrbulescu Original Message Subject: [so] [Tema3][General]From: Adrian-George GÄVAN via so To: so@cursuri.cs.pub.roCC: Salut! Este ok daca am folosit “assert” pentru verificarea valorilor de return a apelurilor de sistem in loc de macroul DIE? Multumesc anticipat! Adrian Gavan ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
Re: [so] [Tema3][General]
2016-04-02 14:48 GMT+03:00 Mihai Catalin Arsenescu via so < so@cursuri.cs.pub.ro>: > Buna ziua / Salut, Salutare, > 1. Fie cazul in care se scrie intr-o pagina care nu a fost alocata in > RAM(STATE_NOT_ALLOC). > Din enunt: > > În momentul generării unui page fault și a alocării unei pagini > fizice, pagina virtuală este marcată read-only. Dacă accesul a fost de > scriere, se va genera un nou page fault și se va marca pagina > read-write. Astfel, un acces de citire la o pagină nemapată va genera > un page fault, iar pagina va fi mapată și marcată read-only. Un acces > de scriere la o pagină nemapată va genera două page fault-uri, iar > pagina va fi mapată și marcată read-write. > > 1.1. Nu inteleg cum putem stii ce acces a fost; eu nu gasesc in > structura siginfo_t un camp care sa reflecte acest lucru. Acest > comportament(2 semnale la write) trebuie luat ca atare? Adica la un > acces de write se va apela de 2 ori handler-ul nostru fara ca noi sa > implementam acest lucru? Daca da, cum stim ca apelul este de write > sau read ? Simulatorul trebuie să știe ce protecție are fiecare pagină, doar el este entitatea care gestionează paginile virtuale. Dacă pagina este nealocată, la un acces de scriere se generează un page fault pentru care pagina este mapată în RAM cu protecție read-only. Imediat se generează un nou page fault din cauza protecției iar pagina este marcată read-write. În acest moment operația de scriere se poate realiza cu succes. > 1.2. Luand in calcul > Pentru a implementa logica de demand paging și cea de swapping > trebuie să interceptați page fault-urile produse în momentul unui > acces nevalid la o zonă de memorie. La interceptarea page > fault-urilor, folosiți modificări succesive ale drepturilor paginilor > pentru a implementa logica temei. La început, paginile nu au niciun > drept (PROTECTION_NONE)., > se vrea implementat urmatorul comportament? > > La primul acces la o memorie nemapata: se mapeaza in RAM si se face READ_ONLY > La al doilea acces(primul acces la o memorie mapata): se muta in RAM > si se face READ_WRITE. > Da, pentru primul acces. Al doilea fault apare la un acces de scriere dar pagina este deja în RAM (dacă între timp nu a fost mutată în swap), deci se modifică doar protecția ei. > 1.3. Putem primi page fault pentru o pagina care se afla in RAM? Daca > da, acesta se datoreaza permisiunilor de acces? Da, pentru ambele întrebări. > 2. Prin mapare peste RAM se intelege demaparea din memorie > virtuala(unmap) si maparea(mmap) peste descriptorul de fisier RAM ? Da. Adrian ___ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
