• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/35

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

35 Cards in this Set

  • Front
  • Back
  • 3rd side (hint)
What is a computer that resides in memory only?
Java Virtual Machine
Coffee Machine
What Machine enables Java programs to be executed on a variety of platforms opposed to the one platform that only the one platform for which the code is compiled
Java Virtual Machine
Why is Java portable?
JVM
What is the reason that JAVA is portable?
It provides a layer of abstraction between the compiled Java program and the underlying hardware platform and operating system
Is JVM small or large when implemented in RA?
Small-It is purposely designed to be small so that it can be used in a variety of consumer electronics
Is Java Source Code compiled to the bytecode level or bitcode level?
Java source code is compiled to the bytecode level, as opposed to the bitcode level. The JVM executes the Java bytecode
What extension does the javac program read and convert files?
The javac program, which is the Java compiler, reads files with the .java extension, converts the source code in the .java file into bytecodes, and saves the resulting bytecodes in a file with a .class extension
What kind of file does jVM read the stream of bytecode from?
The JVM reads the stream of bytecode from the .class file as a sequence of instructions. Each instruction consists of a one-byte opcode, which is a specific and recognizable command, and zero or more operands (the data needed to complete the opcode
What are four parts to the JVM:
Stack,Registers,Garbage-collection heap,Method area
What is the size of address of in JVM?
32 bits
Each register in the JVM stores?
one 32-bit address
The four parts of JVM reside where?
The stack, the garbage-collection heap, and the method area reside somewhere within the 4G of addressable memory
Java is limited to what size for each single method?
Java methods are limited to 32K in size for each single method.
The JVM uses the following to manage the system stack?
Program counter Keeps track of where exactly the program is in execution.


• Optop Points to the top of the operand stack.


• Frame Points to the current execution environment.


• Vars Points to the first local variable of the current execution environment
Why did the Java development team decide on using the amount of registers they did?
The Java development team decided that Java would only use four registers because if Java had more registers than the processor it was being ported to, that processor would take a serious reduction in performance
Where are perimeters stored in JVM?
The stack is where parameters are stored in the JVM
The JVM is passed to the bytecode from the Java program and creates a stack frame for each method. Each frame holds three kinds of information:
Local variables An array of 32-bit variables that is pointed to by the vars register.


• Execution environment Where the method is executed and is pointed to by the frame register.


• Operand stack Acts on the first-in, first-out principle, or FIFO. It is 32 bits wide and holds the arguments necessary for the opcodes. The top of this stack is indexed by the optop register.
The JVM has two other memory areas
Method


• Constant pool
The JVM handles the following primitive data types?
byte (8 bits)


• float (32 bits)


• int (32 bits)


• short (16 bits)


• double (64 bits)


• char (16 bits)


• long (64 bits)
How many steps to constructing secuity mechanism?
I propose a six-step approach to constructing a viable and flexible security mechanism
The Security Problem Defined?
A program arriving from outside the computer via the network has to be greeted by the user with a certain degree of trust and allowed a corresponding degree of access to the computer's resources to serve any useful purpose. The program is written by someone else, however, under no contractual or transactional obligation to the user. If this someone is a hacker, the executable content coming in could be a malicious program with the same degree of freedom as a local program
Does the user have to restrict completely the outside program from accessing any resource whatsoever on the computer?
Of course not. This would cripple the ability of executable content to do anything useful at all.
A more complete and viable security solution strategy would be a six-step approach:
Anticipate all potential malicious behavior and attack scenarios.


2. Reduce all such malicious behavior to a minimal orthogonal basis set.


3. Construct a programming environment/computer language that implicitly disallows the basis set of malicious behavior and, hence, by implication, all potential malicious behavior.


4. Logically or, if possible, axiomatically prove that the language/environment is indeed secure against the intended attack scenarios.


5. Implement and allow executable content using only this proven secure language.


6. Design the language such that any new attack scenarios arising in the future can be dealt with by a corresponding set of countermeasures that can be retrofitted into the basic security mechanism.
Working backwards from the previous solution strategy, the security problem associated with executable content can be stated as consisting of the following six subproblems
What are the potential target resources and corresponding attack scenarios?


• What is the basic, minimal set of behavioral components that can account for the previous scenarios?


• How should a computer language/programming environment that implicitly forbids the basis set of malicious behavior be designed?


• How can you prove that such a language/environment is, indeed, secure as claimed?


• How can you make sure that incoming executable content has, indeed, been implemented in and originated from the trusted language?


• How can you make the language future proof (extensible) to co-opt security strategies to counter new threats arising in the future?
Attack scenarios could belong to one of the following categories and have one of the following goals (this is not an exhaustive list
Damage or modify integrity of data and/or the execution state of programs.


• Collect and smuggle out confidential data.


• Lock up resources, making them unavailable for legitimate users and programs.


• Steal resources for use by an external, unauthorized party.


• Cause nonfatal but low-intensity unwelcome effects, especially on output devices.


• Usurp identity and impersonate the user or the user's computer to attack other targets on the network.
Specifically, the Java security model covers the following potential targets
Memory


• OS/program state


• Client file system


• Network

against the following attack types listed in Table 2.1:


• Damage integrity of software resources on the client machine. Achieved by what is usually called a virus. A virus is usually written to hide itself in memory and corrupt specific files when a particular event occurs or on a certain date.


• Lock up/deny usage of resource on the client machine. Usually achieved by a virus.


• Smuggle information out of the client machine. Can be done easily with UNIX SENDMAIL, for example.


• Impersonate the client machine. Can be done through IP spoofing. This style of attack was brought to the attention of the world by Kevin Mitnick when he hacked into one of computer security guru Tsutumo Shimura's personal machines. The whole incident is well-documented in the New York Times best-selling book Takedown by Tsutumo Shimura.
Instead of arriving at a basic set of malicious behavior, Java anticipates a basic set of security hotspots and implements a mechanism to secure each of these:
Java language mechanism and compiler.


• Java-compiled class file.


• Java bytecode verifier and interpreter.


• Java runtime system, including class loader, memory manager, and thread manager.


• Java external environment, such as Java Web browsers and their interface mechanisms.


• Java applets and the degrees of freedom allowed for applets (which constitute executable content).
Design Security Architecture Against Previous Behavior Set
Construct a programming environment/computer language that implicitly disallows the basic set of malicious behavior and hence, by implication, all potential malicious behavior. You guessed it—this language is Java!
Prove the Security of Architecture
This step involves logically or, if possible, axiomatically proving that the language/environment is indeed secure against the intended attack scenarios.


Security mechanisms built into Java have not (yet) been axiomatically or even logically proven to be secure. Instead, Java encapsulates all its security mechanism into distinct and well-defined layers. Each of these security loci can be observed to be secure by inspection in relation to the language design framework and target execution environment of Java language programs and applets.
The Java class file checker and bytecode verifier achieve this objective.
Restrict Executable Content to Proven Secure Architecture
Restrict Executable Content to Proven Secure Architecture
Make Security Architecture Extensible
Design the language such that any new attack scenarios arising in the future can be dealt with by a corresponding set of counter-measures, which can be retrofitted into the basic security mechanism
Make Security Architecture Extensible
The first tier of security in Java is
the language design itself—the syntactical and semantic constructs allowed by the language
Classes and methods can be declared as final, which disallows further subclassing and method overriding
Final Classes and Methods
This declaration prevents malicious modification of trusted and verified code.
Final Classes and Methods