assets/developer-notes/stephanie-gawroriski/2014/06/27.mkd

   1 # 2014/06/27
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 I was out doing stuff all day and as such, could not get any coding time down.
  10 _2014/07/21 -- The following was moved from the k8 LaTeX file and placed here
  11 instead._ _Deviations_
  12
  13 Since this is my own implementation, I will make my own decisions for certain
  14 aspects. _Crimped SecurityManager_
  15
  16 The SecurityManager is flawed in that it is essentially a user based check
  17 mechanism in the library. It complicates writing of code and failing to
  18 implement checks for it correctly may result in security vulnerabilities. I
  19 plan to rely on the kernel to perform such checks, so from the aspect of the
  20 program being run it thinks it is able to do whatever it wants. The kernel
  21 will be much better at setting specific limits to the program such as file or
  22 device access. Programs depend on the kernel to access resources anyway, so if
  23 it says no it will be a no rather than a kind no with a smile.
  24
  25 Programmers do make mistakes and it would be foolish if one believes they do
  26 not. A single method not checking the SecurityManager when it should could
  27 result in dangerous losses.
  28
  29 For compatibility reasons, if a process is spawned with a SecurityManager
  30 present then the kernel will emulate it and the permissions it gives. So
  31 rather than being done entirely on the user side it is done on the kernel
  32 side. This also means that either SecurityExceptions could be thrown at any
  33 time or system calls return different values. The kernel will create a new
  34 process which contains no threads so that secured checkPermission calls can be
  35 performed by it. It also permits stacking of SecurityManagers so that if a
  36 process is started by another who has a SecurityManager then that will also be
  37 checked. _Tighter Checks Related to Inner Classes_
  38
  39 Normally, classes outside of a specific class are not permitted to access
  40 specific fields or methods based on their protection status. With the addition
  41 of inner classes in the language, they are essentially outer classes with a
  42 bit of magic to wrap them up. Inner classes and outer classes can obtain
  43 access to their private or protected parts without discretion. To permit this
  44 in the language the compiler adds bridge methods used to access such pieces or
  45 methods. However, those pieces may at least be package private and they might
  46 even be public. So any methods that are marked as bridge or synthetic will
  47 need to have additional and a bit more complex checks to handle inner classes.
  48 _Avoid System Threads_
  49
  50 System threads are essentially extra threads that do stuff such as garbage
  51 collection or checking the time in a for loop. Since the kernel is the virtual
  52 machine it can just do this directly and requires no user space intervention.
  53