Virtuelt minne er en metode som brukes for å utvide/frigjøre fysisk minne. Deler av informasjonen som oppbevares i fysisk minne, blir mellomlagret på masselager og hentet inn ved behov. En umiddelbar ulempe ved bruk av virtuelt minne er at aksesstiden til et typisk masselager er betydelig høyere. Informasjon lagret i fysisk minne er gjerne lagt der med ønske om rask aksess. Når det blir behov for mindre viktige data lagret i virtuelt minne, må naturlig nok prosessen som ønsker disse dataene vente lenger enn normalt. I korte trekk kan man si at problemet med virtuelt minne er en degradering av effektiviteten til systemet.
Stikkord; cache.
Caching av diskaktivitet; en del av minnet settes av som en mellomlagring mellom masselager og minne. Denne plassen administreres av OSet og avsettes plass til i RAM. Det er gjerne en fordel at cachingen er "smart" og mellomlagrer informasjon som ofte blir brukt. På den måten kan OSet hente informasjon fra minnet, og dermed redusere responstiden, samt redusere antall tilganger til disken.
Jeg synes denne oppgaven er svært vag, og vet ærlig talt ikke hva det spørres etter. Stort sett all programvare baseres på en eller annen form for input og output. Siden oppgaven ligger under "Filsystemer", kan jeg anta at det er snakk om programmer som ønsker å ta vare på, og gjenbruke data fra gang til gang. Evt, produsere rapporter eller prosjekter. I så måte vil idéen være at brukeren skal slippe å huske personlige konfigurasjoner av programmer, samt kunne lagre uferdig arbeid og hente det fram for å jobbe videre seinere.
OSet holder rede på hvilke filer som er i bruk i en egen tabell, den aktive filtabellen, samt at administrativ informasjon om filene kan lagres her for raskere tilgang senere. Bruk av open/close-kommandoer påvirker denne, en open-kommando legger til en fil mens close-kommandoen fjerner en fil. På flerbrukersystem er det en tabell til før den aktive filtabellen, systemfiltabellen, hvor administrativ informasjon unik for hver prosess legges, samt pekere til riktig plass i den aktive filtabellen, hvor felles info. lagres.
Open/Close kan erstattes med Read/Write med innebygd seek, men open/close benyttes av optimaliserings-, vane og bekvemmelighetsårsaker (ett kall fra programmers synspunkt istf. for flere).
Hvor forskjellige det logiske filsystemet er fra det fysiske avhenger en del av hvor avansert det logiske filsystemet er. Tradisjonelt har det logiske fs'et holdt styr på "filer" som består av bytestrings eller samlinger av bytestrings, og overhodet ikke tolket disse på noen måte, bare sendt dem videre til andre programmer, mens det fysiske filsystemet oversetter bytestrengen til den fysisk adresse som siste post før i/o, forsøkt å minimalisere bruken av i/o, tatt seg av komprimering/pakking (for å begrense internfragmentering), kort sagt vært laget før hardware tar over.
/b/c/1/d/8cd ../../7 cd ..mkdir f/3/MNFIT222rmdir ../../../MNFIT222Filer kan lagres på forskjellig vis, som hver har sine fordeler og ulemper.
En fil kan lagres sammenhengende på lagringsmediet, alt man behøver for å finne igjen hele filen da er en peker til starten på denne blokken. Løsningen er praktisk når mediet er bånd, fordi hele filen kan skrives i en omgang uten søking på båndet. Randomisert tilgang blir også mer effektivt og enkelt fordi filen er samlet.
Problemet er at man må vite filstørrelsen før man lagrer for å finne en egnet plass, samt at mediet lett blir fragmentert slik at man ikke får lagret en stor fil fordi den ledige plassen er spredd utover mediet. En løsning på dette er å kjøre jevnlig defragmentering.
Man deler mediet inn i blokker av en gitt størrelse, og filer spres over alle blokker. I begynnelsen av hver blokk er det satt av noen få tegn til å peke til neste blokk, hvis noen. Dermed kan man traversere hver blokk for å få hele filen, og i katalogen er det fortsatt bare en referanse til første blokk.
Blokkene kan være plassert hvor som helst på mediet, og man unngår derfor fragmenteringsproblemene. (Derimot kan blokkene være plassert slik at sekvensiell lesing vil bli tregere fordi de ikke er samlet). Randomisert lesing blir veldig tregt fordi operativsystemet må lese seg igjennom alle blokkene for å finne ut hvor den søkte blokk faktisk befinner seg. I tillegg mister man litt effektivitet siden det blir verre å få blokkstørrelsen til å gå opp i en toerpotens (fx. 1024, 2048, 4096, henholdsvis 210, 211, 212 med en peker først i diskblokken.
Ved å skille pekerne ut ifra blokkene og samle dem i en tabell, blir forrige scenario ganske forbedret. Man har en tabell for alle blokkene, siden blokkene jo bare er med i en fil om gangen. Dermed blir hele blokken frigjort for data, og samtidig blir randomisert lesing mye mer effektivt, ved å ha tabellen i minnet.
Ulempen er at tabellen kan vokse ganske kraftig med antallet blokker. Dette er en av årsakene til at MS-DOS (som bruker FAT - file allocation table) har en begrensing på maksimal partisjonsstørrelse på 2 GB. (64k blokker hver av størrelse 32 kB, som er rimelig stor blokkstørrelse som fører til mye sløsing).
En løsning bl.a. UNIX benytter seg av er å la hver fil være representert av en i-node. En i-node er en liten tabell over blokkene filen er sammensatt av. Dersom filen er liten er det nok med denne i-noden til å peke på fx. 10 blokker. Er filen større er det en egen peker i i-noden som går til en egne blokk avsatt til nye pekere til blokker med data.
Gir dette fortsatt ikke nok blokker er det en egen peker i i-noden som kan settes til enda en blokk som blir brukt, denne da med pekere videre til nye pekerblokker. Man kan også ha et tredje nivå, som da vil peke til en pekerblokk med pekere til andre pekerblokker, som hver har pekere til andre pekerblokker, som så har pekere til de blokkene som inneholder blokker. (ble dette litt mange blokker å holde styr på i tankerekken ja?)
Hver inode inneholder typisk også annen informasjon om filen for å skille dette ut ifra katalogen, slik at man kan lenke til inoden fra flere kataloger uten å få inkonsistente filattributter.
Kilder: Tanenbaum, linux/fs/fat/inode.c, chmod(1), mknod(1)
Komprimering av filer er prosessen der man reduserer den fysiske størrelsen til en fil. Komprimering kan enten være såkalt lossy eller lossless. I korte trekk betyr det at lossy komprimering fjerner data fordi den er av mindre verdi, eller kan helt eller delvis rekonstrueres ved interpolering. Denne typen komprimering er ikke interesant å bruke på eksekverbare filer, siden man da kan miste informasjon som står i direkte tilknytning til maskinkoden. Lossy komprimering brukes gjerne på filformater som inneholder bilder og animasjoner.
Som navnet antyder, er lossless mer konservativ, og bevarer all data intakt til tross for redusering i filstørrelse. Denne typen komprimering er mer passende for eksekverbare filer og tekst.
En umiddelbar fordel med filkomprimering er at man begrenser mengen data på masselager. Man får i realiteten plass til å lagre større mengder data på mindre plass. Spesielt interessant kan det være å komprimere om man har data som det sjelden er behov for. Disse dataene kan pakkes og legges til side (arkivering) til det blir bruk for dem. Ellers vil komprimering være nyttig for å minske forbruk av båndbredde.
Det er flere "ulemper" med komprimering;
For det første er erstatningskomprimering basert på LZW-algoritmen, en algoritme som faktisk er patentert og brukt i GIF-filformatet. Kompressjonsforholdet mellom LZ78 og dens forgjenger LZ77 er omtrent likt. Fordelen LZ78 har over LZ77 er at man slipper unna med ferre strengsammenlikninger i hvert steg under kodingen.
Erstatningskomprimering går ut på at man finner fram mer eller mindre "ord" som opptrer hyppig i filen. Man lager seg
en tabell over disse ordene, og erstatter ordene i filen med en referanse til tabellen.
Hvis jeg skulle komprimert de to foregående setningene, ville jeg f.eks. valgt ut "ord", "tabell" og "erstat". Disse ville
jeg lagt i en tabell med referansene: OR, TA og ER. Ved dekomprimering av fila, slår jeg opp i tabellen og erstatter alle "OR, TA,
og ER" med ordene av full lengde fra tabellen. Det er også viktig å understreke at "ord" er brukt symbolsk i forklaringen, da
det ikke er nødt til å være et listet norsk ord, godkjent av Norsk språkråd, men sammenliknbare strenger. ;)
Her antar jeg at det er spørsmål om DriveSpace(TM)
DriveSpace er et diskkomprimeringsprogram laget for MS-DOS. Som andre eksterne og interne komprimeringsprogrammer er formålet å lagre mer informasjon på mindre plass ved å lagre filene mer "effektivt". DriveSpace adminisrerer selv komprimeringen og dekomprimeringen, slik at brukeren kan konsentrere seg om andre ting. DriveSpace opererer på hele volumer av gangen, enten det er snakk om platelager eller RAM/RAMDrives. Bakdelen med DriveSpace er ineffektivitet. DriveSpace fungerer slik at den lager kryssreferanser til repeterende data.
Selvsagt finnes det andre komprimeringsverktøy (eksterne sådanne), som er ment til arkivering/komprimering av enkeltfiler. Eksempler på slike er; ARJ, LZH, LHA, osv...
Kilde: MS-DOS 6.22 Help DriveSpace Tips
VIII) Ta utgangspunkt i et filsystem og lag et lite essay om arbeidsgangen og hvordan dette filsystemet løser de enkelte oppgavene.
Idag skal vi snakke om ext2. ext2 er det primære filsystemet i operativsystemet GNU/Linux, og er bygget etter samme prinsipp som mange filsystemer for UNIX, dvs. med inndeling i blokker og organisering vha. i-noder.
Filsystemet i GNU/Linux er organisert i kataloger som i UNIX, med en rot med underliggende trestruktur av filkataloger. ext2 tillater flere spesialfiler: To forskjellige slags enhetsfiler, blokk- eller tegnbasert. Blokkbaserte enhetsfiler kan buffres. FIFO-filer er en type spesialfil som opptrer som et rør, en prosess kan lese data ifra spesialfilen og en annen kan sende til den, og spesialfilen vil da virke som et rør direkte mellom prosessene uten at dataene mellomlagres på mediet. I tillegg til symbolske lenker finnes selvsagt også vanlige filer og katalogfiler. Det skilles ikke mellom tekstfiler og binærfiler i ext2.
Katalogfilene inneholder oppføringer av filer med navn og i-nodereferanse. Resten av informasjonen knyttet til en fil er lagret i i-noden, såsom eierskap (navn og gruppe), tilgangsrettigheter (les/skriv/kjør for eier/gruppe/andre, for en katalog gir kjør rett til å gå inn i katalogen, les rettighet til å liste oppføringene i katalogen og sticky-biten hindrer en bruker å slette filer i en katalog som ikke er hans egne, selv om han har skrivetilgang. (fx. i /tmp), i tillegg til set-id for bruker og gruppe og "save text image"), antall linker til i-noden, om den er spesialfil, isåfall hvaslags spesialfil indikert med major og minor enhetsnummer. I-noden inneholder også dato for opprettelse, endring og sist tilgang.
Når en fil opprettes blir det først funnet en ledig i-node på filsystemet. I-noden får så satt eierskap, tilgangsrettigheter og datoer. Deretter blir det lagt til en oppføring i katalogen filen opprettes i, hvis man nå har skriverettigheter der. Hvis ikke må i-noden slettes igjen. Når det er laget en oppføring i katalogen for i-noden blir "antallet lenker" for i-noden øket med 1, dvs. fra 0 til 1.
Når det skrives til filen blir først tilgangsrettigheter til filen sjekket. Er alt ok blir det funnet blokker på filsystemet. Pekere til hver blokk blir plassert i i-noden, er filen blir det opprettet blokkpekerblokker som beskrevet i oppgave VI.
Opprettelse av en katalog skjer som for filer, i tillegg
blir det opprettet to oppføringer i katalogen, hardlenkene
.
og ... Førstnevntes i-nodereferanse
er til katalogens egen i-node, og den andres referanse
er til katalogen som inneholder denne katalogen. Dermed blir
. og .. enkle referanser til
gjeldende og forrige katalog.
ext2 støtter også symbolske lenker, som rett og slett inneholder en referanse i det logiske filsystemet som et stinavn. Harde lenker vil si at en inode er referert til flere ganger. I i-noden viser referansetelleren hvor mange ganger den er referert til. Når en i-nodes referanseteller er 0 kan den slettes, såfremt den ikke er åpen.
Kilder: linux/fs/ext2/inode.c, linux/fs/ext2/dir.c, linux/fs/ext2/namei.c
Sikkerhet i et operativsystem har flere sider; både å sikre mot tap av data (dette kan skje ved systemcrash eller hardwarefeil), og sikkerhet mot at personer/programmer får tilgang til noe de ikke skal ha tilgang til. Det siste kan også medføre det første; et program som får tilgang til noe det ikke skulle hatt tilgang til kan føre til at data går tapt.
Sikkerhet innebærer å holde oversikt over at ikke systemet er sårbart, å holde styr på sine brukere (at de ikke gir bort passord, har dårlige passord, sender passord over ukrypterte forbindelser osv.), samt å begrense risiko i "gråsone-områder", dvs. tjenester/funksjoner som innebærer en sikkerhetsrisiko, men vil gjøre systemets bruksverdi svært liten. Det er mye mer til sikkerhet også; i det hele tatt er det et svært komplekst område som griper inn i alt fra utvikling av systemet, utvikling av programmer som skal kjøre på systemet, installasjon og konfigurasjon, og den daglige drift av systemet. Nettverk, og da særlig internet, gjør det hele enda mer komplekst, fordi man blir nødt til å ta hensyn til forbindelser utenfra, med alt dette gir av nye muligheter for problemer.
Som en felles kjent av gruppemedlemmene har uttalt:
"Å jobbe med datasikkerhet er omtrent som å spikke fliser med motorsag, og være nødt til å passe på hvor hver eneste flis blir av etterpå. Derfor forsøker jeg å unngå å jobbe med datasikkerhet" (Mølls postulat om datasikkerhet)
Selv om det kan høres useriøst ut er det mye sannhet i dette.
Beskyttelsesmekanismer består av to deler; policy (hva som skal beskyttes mot hvem) og mekanisme (hvordan systemet skal overholde policyen.) I UNIX representeres f.eks. beskyttelsespolicy i filsystemet i bits for lese, skrive, og utfør for filens eier, gruppe, og for alle. Mekanismen er uavhengig av dette, men bruker denne informasjonen til å gi tilgang til det en bruker skal ha tilgang til.
Tap av data kan komme av hardwarefeil, systemcrash, dårlig skrevne programmer, brukerfeil, og ondskapsfulle programmer/personer. Mye av dette kan operativsystemet eller hardwaren håndtere og sikre mot, stikkord kan være redundante disker, feilkorrigerende minne, beskyttet minne, brannvegger osv., men noen ting er litt vanskeligere; å beskytte mot brukerfeil kan f.eks. gå ut over systemets funksjonalitet. Mange sikkerhetstiltak i forhold til ondskapsfulle personer kan også virke forringende for systemet; mange nettverkstjenester medfører f.eks. kjente sikkerhetsrisiki, uten at man stenger dem av den grunn.
Aktiv inntrenging går ut på at inntrengeren må skaffe seg adgang ved å cracke passord, eller snuke fram bakdører/exploits. Passiv inntrenging skyldes dumme brukere som installerer programmer med bakdører i, trojanske hester som feks Back Orifice.
Kryptering har til hensikt å gjøre data uleselige med mindre man har
rett passord eller nøkkel. Å kryptere data vil i praksis si at dataene
blir behandlet av en algoritme som returnerer data helt
uforståelige, dette kalles siffering.
Fx. kan teksten "blomsten trenger vann" bli kryptert til
"SADjks90dfsdf908sadfsjlkadfjasf". For å lese teksten må
de krypterte dataene igjennom en dekrypteringsalgoritme.
Det finnes forskjellige måter å kryptere på, en av de enkleste lærte da vi i Mikke Mus detektivklubb, fx. å bytte ut alle a'er med c'er, b'er med d'er, etc. Algoritmer for kryptering kan basere seg på et passord eller nøkkelpar. I en passordalgoritme gir man et passord sammen med dataene. For å dekryptere trenger man samme passord.
En annen måte å kryptere på, som er litt mer finurlig, er ved nøkkelpar. Den baserer seg på at man har to nøkler. Den ene nøkkelen brukes under kryptering, og den andre under dekryptering. Hvis man har nøkkelparet nøkkelA og nøkkelB, og krypterer Data med nøkkelA, kan man bare dekryptere kryptertData med nøkkelB.
Ved å bruke to nøkkelpar kan man la hvert av nøkkelparene ha en "privat" og en "offentlig" nøkkel. To parter som vil kommunisere kryptert utveksler da sine offentlige nøkler, men holder hver sine private nøkler hemmelig. En algoritme kan da bruke senderens private nøkkel sammen med mottakerens offentlige nøkkel, og kryptere på en slik måte at man kun kan dekryptere med senderens offentlige nøkkel og mottakerens private nøkkel. Begge partene kan da være sikre på hvem som er sender og mottaker.
En krypteringsalgoritme bør være slik at det er umulig å bryte krypteringen med mindre man har riktig passord/nøkkelpar eller prøver hver eneste mulige passord/nøkkelpar, såkalt brute-force-cracking. Hvis krypteringen er god bør det være så mange mulige løsninger at det ikke blir praktisk gjennomførbart å bryte krypteringen selv om man samler enorme datakrefter. I nøkkelparsystem må det også være umulig å regne seg frem til den offentlige nøkkelen fra den private nøkkelen eller omvendt.
Det kan se ut som om datakriminalitet (IT-kriminalitet heretter) er ganske løst definert i Norge. IT-kriminalitet er en rimelig "ny" type kriminalitet. I alle fall er det ikke lenge siden staten begynte å bry seg om den, og ta den på alvor. Økokrim har valgt å definere den slik:
I Norge, og verden forøvrig, er vel piratkopiering den mest utbredte formen for datakriminalitet. Per definisjon er det ulovlig bare å laste ned opphavsrettslig beskyttet programvare, uten samtykke fra produsenten, og er dessuten straffbart ved åndsverksloven §54.
For å få bukt med de stadig økende problemene mtp IT-kriminalitet, ser det ut til at initiativ til "nettpoliti" begynner å gjøre seg gjeldende. Britisk politi har f.eks. startet et prosjekt som involverer den typen politi-strategi. Denne nye seksjonen av politiet skal fokusere på økonomisk kriminalitet, sabotasje, pornografi og organisering av pedofile sexreiser på web. Det verserer dessuten forslag om et samarbeid mellom norsk politi og FBI, siden IT-kriminalitet sjelden holder seg innenfor landegrensene.
Problemet med sikkerhet og webbrowsere oppstår i hovedsak når man tar i bruk "aktivt" innhold som java, javascript, og ActiveX. Slikt innhold skal gjøre noe som er "smartere" enn å vise statiske websider, og må derfor få rettigheter på systemet. Dette gir mulighet for ondskapsfulle programmer til å utnytte disse rettighetene - og dermed lese filer på maskinen. Et annet problem kan være kjente svakheter i browserne som gjør at en webside skrevet på en spesiell måte kan crashe dem - dette kan være svært plagsomt for brukerne.
Andre problemer kan ligge i protokollen - en usikret http-forbindelse kan "hijackes", og misbrukes av ondsinnede personer. Dessuten kan informasjonen som sendes over en slik forbindelse avlyttes. Dette kan man dog unnslippe ved å bruke secure http.
Digitale signaturer innebærer at man ved hjelp av kryptografi kan verifisere at et dokument virkelig kommer fra den som det utgir seg for å komme fra. Dette er, og vil bli, svært viktig - både for elektronisk handel og for andre ting det det er av stor viktighet å kunne verifisere hvor dokumentet kommer fra.
Den tekniske løsningen er basert på private og offentlige nøkler. Det du krypterer med din private nøkkel kan kun dekrypteres med din offentlige nøkkel. Sender sender sjekksummen av det man signerer på kryptert slik, og dermed kan mottaker sjekke at denne sjekksummen dekryptert stemmer overens med sjekksummen han selv kan regne seg frem til. Man kan også gjøre dette på hele teksten, men det er svært ressurskrevende.