flash memory ( fm ) technology is very attractive for bios device implementations because it allows the contents of bios devices to be easily erased and reprogrammed on board , by user operated software that does not require any special skills . for these reasons , fm devices are very vulnerable to malicious attacks such as computer viruses . allowing changes of critical sections of the computer bios code to be performed by software dangerously exposes the bios code to executables that may be infected by viruses . a typical attack on an fm device may be through a virus program that will initiate an update of the fm without the user &# 39 ; s knowledge . alternatively , such attacks may be performed by interfering during an fm update initiated by the user , or even by the modification of the information received by the user for the purpose of update ( especially when downloaded from the internet ). prior art fm protection methods usually use hardware and software to restrict access to the fm device blocks . however , in general these methods are not adequate since the operations of fm management are still performed by the host processor . moreover , since the content of the fm device needs to be updated from time to time , software must be provided to enable alterations of the access protection settings . therefore , a virus or another parasite may program the device protection mechanism to suit its own needs , and utilize the device &# 39 ; s service procedures to access its content . as for viruses , the results of such attacks are usually the cause of damage to the proper operation of the computer , which in many cases require the intervention of a skilled technician to correct . such attacks may also cause an irreversible loss of information or even permanent damage to the system . the present invention teaches a method for fm device protection in which an embedded controller ( ec ) is utilized to manage and control the device protection and access permission . the ec has access priorities and may change the access permission settings that were given initially to other components of the system . moreover , the ec is alerted as access attempts to restricted areas occur , and it is capable of blocking any further access attempts when required . the ec code and operation are not observable to other parts of the system , and according to an advantageous embodiment of the invention , codes of critical importance ( e . g ., boot section ) are stored in special fm sections which are write - protected to either the ec and the host processor . to enable flexibility of the host &# 39 ; s access permission settings , software is used to restrict or permit the host processor access to some parts of the fm . the host and ec access restrictions are initially set by the system at start - up . during operation , the host may change some of those settings , but the ec has superior priority over any of the host access enable settings , and may override the host settings at any time . in this fashion , sophisticated and efficient protection schemes are implemented . fig1 schematically illustrates the access paths , and access control to a fm device according to an advantageous embodiment of the invention . in the figure , fm device 140 comprises two independent fm blocks . the main block 120 , which serves as a base memory , is used to store programs and constant data of the embedded controller ( ec ) 100 and the host processor 101 . the second fm block is the information block 130 , which contains the device &# 39 ; s specific parameters and user defined data . to enable different access levels to different types of classified information , the fm blocks are partitioned into separate sections , as illustrated in fig1 . the main protected sections in main block 120 are : ec boot block 121 — a section dedicated for the ec boot code , and protected from corruption by the ec or host . host boot block 122 — a section dedicated for host boot codes , and protected from corruption by the host . “ other ” parts 123 — this section is dedicated for general purpose , and the software enable / disable its protection . factory parameters 131 — this section holds various parameters and calibration information defined during the device &# 39 ; s production , and is protected from all alterations , while the device is inserted in the system . protection word 132 — this section contains information about the flash data protection , which is used to restrict write or erase access to parts of or the entire fm device . only the jtag or the parallel interface ( i / f ) may change this . “ other ” parts 133 — this section is dedicated for general purpose , and its read and write is allowed for the jtag , the parallel i / f and the ec software . the fm blocks are further partitioned into smaller sections , known as pages . read and program operations are performed at the byte or word level , while the erase operation is performed at the page level or at the section level ( sections are the combination of several consecutive pages into a larger memory section that may be erased at one time ). in program operations , bits in the flash are modified from a logic value of “ 1 ” to a logic value of “ 0 ”. in erase operations bits in the erased area ( page or section ) are all set to a logic value of “ 1 ”. the fm device may be read , written or erased through several access paths 110 – 113 , with different levels of fm contents protection . the access paths are : the jtag path 110 , the parallel interface path 111 , the ec path 112 , and the host path 113 . before discussing an advantageous embodiment of the invention in detail a brief discussion of the parallel interface ( i / f ) and the jtag interface ( i / f ) would be helpful . the parallel interface is used during the testing of the device as part of its manufacturing process . at this phase the “ factory parameters ” are loaded into the device . it may be also used for programming the fm prior to assembling it in the system , using a special memory programmer ( such as those commercially available from data i / o ). the jtag interface is used to program the fm after it is assembled in its application board ( or as an option for a pre - assembly programming as well ). this may be done as part of the final system manufacturing , during the debug process of the flash contents or as part of failure recovery performed by a trained technician . the access attempts performed via the access paths 110 – 113 are controlled by the arbitration unit 102 , which permits or restricts the requested access . a protection mechanism 103 is utilized to direct arbitration unit 102 as to the access privileges of the different access paths 110 – 113 . the access permissions , as will be explained later , depend on the access path that is utilized and on the flag settings in protection word 132 . the access to the different fm device blocks is further protected by an access permission scheme , implemented by access control 104 . in access control 104 , software and hardware protection means are combined to generate a set of access permission levels for the various operations ( i . e ., read , program and erase ) which are available for the host , for the ec , through the jtag i / f and through the parallel interface . the arbitration unit 102 provides access to the fm device in accordance with the protection mechanism 103 settings . the protection mechanism 103 holds the information regarding the size of the ec and host boot sections , 121 and 122 respectively . thereby , the access permission to the ec and host boot sections is granted in respect to the protection mechanism 103 settings . protection mechanism 103 is further used to disable access via the jtag and parallel i / fs , which are mainly used during the device &# 39 ; s manufacture testing , and system manufacturing , testing and maintenance . in fig3 a , protection word 132 is depicted . protection word 132 is stored in the flash protection word and is read into a register after every reset and after every update of the flash by the jtag i / f or the parallel i / f . bits 0 – 3 of protection word 132 define the size of the ec boot block . for example , setting 0 – 3 bits to “ 1000 ” will allocate a forty eight kilobyte ( 48 kbyte ) ec boot block . bit 4 of protection word 132 defines the use and size of the host boot block section . when bit 4 is clear , this bit specifies a sixty four kilobyte ( 64 kbyte ) area at the end of the memory , otherwise the boot block section is not available . bits 7 , 8 and 9 of protection word 132 enable fm contents protection from access attempts initiated by the jtag interface and by the parallel interface . when any one of these bits is cleared to zero (“ 0 ”), all parallel interface and jtag operations are disabled except for “ special erase ”. “ special erase ” is an operation in which the entire contents of the fm are erased and thus any secret kept in it is destroyed . protection word 132 is read by hardware from information block 130 , as part of the reset sequence . once the protection word bits are read , the main block partitioning is established and the host and ec paths access restrictions can be determined by protection mechanism 103 . the fm sections , whether accessed by the ec or the host , will be referred to hereafter as the shared memory . fig4 schematically illustrates the host and the ec shared memory access control scheme , which is implemented by access control unit 104 . access control unit 104 comprises programmable registers and flags , which are utilized to set access permissions to the various sections of the shared memory . host protection flags 401 comprise read , write and lock flags . the flag setting is utilized to define sixty four kilobyte ( 64 kbyte ) block read and write permissions . in this fashion , the read and write flags are used to set access restriction on host access to fm main block sections . the lock flags , when activated , disable any further changes to the specific block flags , until a reset of the system is performed . the host read , write and erase protection flags 401 , can be programmed via the “ shared memory host access protection ” ( smhap ) register 405 . the host protection flags are set during start - up to a pre - defined default setting , and may be reprogrammed later by the host , to enable host read and write operations and even a lock of desired flag settings . if the host activates a lock flag , the block flags &# 39 ; setting is locked and no further changes can take place until a system reset is performed . in addition , for the purpose of supporting ec controlled protection over specific sections , ec 100 can override the host settings by “ ec override host protection ” mechanism 402 . this function is utilized with “ hidden execution schemes .” the override may only take away access rights that the host took to himself . there are two registers : ( 1 ) smcorp 403 in which each of its bits control the override on host read accesses from a specific shared memory block , and ( 2 ) smcowp 404 in which each of its bits control the override on host write accesses to a specific shared memory block . the sections cover the whole address space of the shared memory , using blocks that are equal in size or of various sizes . in a specific advantageous embodiment , the first one hundred twenty eight kilobytes ( 128 kbyte ) of the shared memory use eight kilobyte ( 8 kbyte ) sections and the rest of the memory consists of sixty four kilobyte ( 64 kbyte ) sections . upon reset all host write accesses are blocked and host read accesses are enabled only to the host boot block 122 ( if such a block exists ). access restrictions on the ec access to the fm are imposed via the “ flash core write protect ” ( fcwp ) register 400 . each of the fcwp register &# 39 ; s bits is utilized as a write protect flag dedicated to a specific block ( e . g ., eight kilobyte ( 8 kbyte ) blocks ) of the fm &# 39 ; s main block section 120 . the ec write protection is determined according to the fcwp flags settings . upon reset , the entire main block is write protected from ec write accesses . the ec write protection is intended to prevent accidental erase of sections of the ec flash only . a section that is designated as an ec boot block is always write protected . the ec may change the write protection state of any of the main block sections at any time , except for the host and core boot blocks that are always write protected . the ec read access to any fm section is not limited . it should be noted that in any case , the host cannot access information block 130 . information block 130 does not have dedicated protection bits for ec writes , but some sections of it ( that contain factory parameters 131 and protection word 132 ) are write protected from ec write accesses at all times . fig3 b illustrates the structure of smhap register 405 . in an advantageous embodiment of the invention , each of the smhap flags is responsible for a specific host access permission to an fm block of sixty four kilobytes ( 64 kbytes ). bit “ zero ” ( bit “ 0 ”) of smhap register 405 is utilized for setting the host read protection flag . bit “ one ” ( bit “ 1 ”) is utilized for setting host write protection flag of the block . bit “ two ” ( bit “ 2 ”) is utilized for setting the lock flag of the block . bit “ three ” ( bit “ 3 ”) is utilized to halt the protection flag setting during index update . bits 4 through 7 determine the host access protection index , which is utilized to select the block on which the indicated flags settings should take effect . in this fashion , to modify host block protection flags , bit 3 is set to a logical value of “ zero ” (“ 0 ”) and the desired index is written to bits 4 through 7 and the desired flags are written to bits 0 through 2 . to read the flags settings , the host should write the index of the desired block ( by writing a logical value of “ one ” (“ 1 ”) to bit 3 and the desired index value to bits 4 through 7 ). then the host should read the register . the read returns both the index and the flags . the index should then be compared to the one written , to make sure that no write operation took place by an interrupt routine . if the compare fails the process should be repeated . fig2 schematically illustrates the different access levels available to each of the different fm blocks via the access paths , in an advantageous embodiment of the invention . after the system &# 39 ; s startup is completed , the access control grants each of the access paths a set of access levels to the fm device sections , according to the protection registers and the host read and write protection flags . the access levels available to each of the paths 110 – 113 ( see fig1 ) are set during the device startup sequence ( i . e ., boot ), per information read from a fixed location in the flash named “ protection word ” 132 . these are hardware settings , and some alterations of the settings may take place , as discussed above . with reference to fig2 , the access to main block 120 is permitted to ec 100 , host 101 , the jtag i / f and the parallel i / f . information block 130 access is permitted to ec 100 , to the parallel i / f and to the jtag i / f ( but not to host 101 ). the access levels , read , write and erase , which are available for each of the access paths , are illustrated in the form of arrowhead lines . the ec access levels for main block 120 are : “ other ” main block section 123 — read write and erase (“ rwe ”). “ other ” information block section 133 — read write and erase (“ rwe ”). the host access is very limited in order to avoid unauthorized alteration of sections of critical importance . for this reason , the host boot section is read only (“ ro ”) for host access , and the only section that the host can gain write permissions is the “ other ” section 123 of main block 120 , wherein host read , write and erase functions (“ rwe ”) are permitted . the rest of the fm device sections are completely restricted for host accesses . the host has no access to ec boot block 121 since it does not include any information of interest to the host nor does the host update it . the jtag i / f and the parallel i / f access is only partially limited , since the entire device is programmed and tested through them . still referring to fig2 , rwe access levels are granted to the jtag i / f and to the parallel i / f for the access to the main block 120 sections 121 – 123 , and the “ other ” section 133 of information block 130 . the protection word 132 settings may block jtag i / f and parallel i / f read and write access attempts , through one or more access disable bits . however , only when protection word 132 settings enable the jtag i / f and the parallel i / f read and write access , may the content of protection word 132 be altered . complete erase of the entire flash contents , excluding the factory parameters 131 , is always allowed via the jtag i / f and parallel i / f . this enables the protection of flash contents from snooping attempts through these interfaces . it also protects the information in the flash from any read other than the one allowed by ec 100 . the jtag i / f and the parallel i / f may read and write the contents of protection word 132 , as long as it is not protected . if protection word 132 disables the jtag i / f and the parallel i / f accesses , a special erase command may be initiated by those sources , which erases the entire fm device , except for the factory parameters 131 . the factory parameters 131 may be erased and programmed through the parallel i / f only . its erase is enabled only as part of an extended special erase . this is done to protect the information in this section from an erroneous erase that will cause the loss of information that may be provided only at the factory ( e . g ., parameters achieved during testing ). jtag i / f access to the factory parameters 131 , is read only (“ ro ”), and during manufacturing this i / f may be used to program the device as well . to further illustrate the invention described herein , fig7 a , 7 b and 7 c are provided , in which the access levels are depicted in conjunction with access control 104 and protection unit 103 . in these figures , the access protection is depicted in the form of rings . the outer rings 710 a , 710 b and 710 c schematically illustrate the fm sections 121 – 123 and 131 – 133 . the inner rings ( i . e ., the interior rings which follow the outer rings in order ) 711 a , 711 b , and 711 c schematically illustrate access control unit 104 . the rings 712 a , 712 b , and 712 c ( i . e ., the third rings in order in each of the fig7 a – c ) schematically illustrate access levels according to an advantageous embodiment of the invention . the protection rings are partitioned into two distinct blocks , main block 120 and information block 130 . the rings are further partitioned into the ec boot section ( 121 ), the host boot section ( 122 ), the main block &# 39 ; s “ other ” section ( 123 ), the factory parameters section ( 131 ), the protection word ( 132 ), and the information block &# 39 ; s “ other ” section ( 133 ). as depicted in fig7 a , the protection mechanism does not impose any read access restrictions on ec 100 . however , the scope of the write access levels to the main block 120 host boot block 122 and ec boot block 121 is defined by hardware during reset and obtained by bits 0 through 3 and bit 4 of protection word 132 . the entire main block 120 is protected from ec writes , by the fcwp register 400 that is cleared by hardware on reset . the fcwp bits may be later used to enable write access to the host boot block 122 and “ other ” section 123 of main block 120 . it should be noted that once ec boot block 121 is allocated ( by bits 0 through 3 of protection word 132 ), the respective bits in the fcwp register 400 that determine the access permissions to ec boot block 121 , are set with fixed values and cannot be altered thereafter ( until reset or “ power down ”). in this manner host access to ec boot block 121 is permanently blocked . write accesses by ec 100 to ec boot block 121 are also permanently blocked . in fig7 b the host protection mechanism is described , by rings 710 b – 712 b , which illustrate the access levels scope to the fm sections . the smcorp register 403 , the smcowp register 404 , and the smhap register 405 determine the host &# 39 ; s access control to the fm sections . the smcorp register 403 bits and the smcowp register 404 bits are set by ec 100 to override host access settings defined by the smhap register 405 . the access level depicted in the third ring 712 b illustrates the limitations of the host access . the host never gains access to information block 130 and ec boot block 121 . the host may read the host boot block 122 at main block 120 , and read and / or write the “ other ” section 123 of main block 120 , but only if it is enabled by smcorp resister 403 and / or the settings of smcowp register 404 and smhap register 405 , respectively . upon reset smcorp register 403 and smcowp register 404 are set so that all reads , except from host boot block 122 , are prevented . in fig7 c , the jtag i / f and the parallel i / f read and write accesses are completely enabled or disabled by the settings of protection word 132 ( i . e ., bits 7 through 9 ), as depicted by ring 710 c . no software limitations are imposed by the access control ring , 711 c . the jtag i / f and the parallel i / f access levels are unlimited to most of the fm block sections . the parallel i / f ( read , write and special erase (“ rwe ”) access permissions ) may be used to change factory parameters 131 during manufacturing . the jtag i / f , however , may only read the settings of factory parameters 131 . in addition , the jtag i / f and the parallel i / f are the only access paths that may change the settings of protection word 132 , but only when their access is granted by protection word 132 . at any time a special erase by the parallel i / f or the jtag i / f may be used to completely erase all information from the flash , excluding factory parameters 131 that can be erased only by the parallel i / f . this allows reprogramming of the device when , for example , one of the boot blocks is damaged . the host operations are reflected by the “ shared memory core control and status ” ( smccst ) register ( illustrated in fig3 c ). the smccst control and status is utilized by ec 100 to control and monitor the host operations on the shared memory in general , and the fm device in particular . fig3 c depicts the smccst register bits , wherein bit “ zero ” ( bit “ 0 ”) the “ host read error ” bit ( hrerr ) is utilized to indicate a host read error , indicating an attempt to read from a read - protected space or an out - of - range address . bit “ one ” ( bit “ 1 ”) of the smccst register , the “ host write error ” bit ( hwerr ) is utilized to indicate host write error , when the host makes an attempt to write to a protected memory location or an out - of - range address . this includes attempts to erase protected sections . bit “ two ” ( bit “ 2 ”) of the smccst , the “ host error interrupt enable ” bit ( herrien ) is utilized to enable an interrupt to ec 100 whenever a host error occurs . bit “ three ” ( bit “ 3 ”) and bit “ four ” ( bit “ 4 ”) are the “ host error response ” field that determines the response type on host errors . bit “ five ” ( bit “ 5 ”) of the smccst register is the “ host lock ” bit ( hlock ). this bit is cleared to prevent host write operations to the shared memory . when bit 5 is set it enables host write operations . bit 5 is utilized by ec 100 for arbitrating the long “ blocking ” erase and program operations by the host . bit “ six ” ( bit “ 6 ”) and bit “ seven ” ( bit “ 7 ”) of the smccst register are the host semaphore write bit ( hsemw , 603 in fig6 ) and the host semaphore interrupt enable bit ( hsemie ) respectively . bit 6 and bit 7 are utilized 5 to indicate the host &# 39 ; s operation / state . the operation of bit 6 and bit 7 and will be more fully explained later . the heres field ( i . e ., bit 3 and bit 4 ) of the smccst register has three options for handling error conditions . the selection between them depends on the ability of the host to handle the error condition . the default setting is “ zero zero ” (“ 00 ”) and is selected after reset . in this case , read operations are extended using a not ready indication ( for example “ long sync ” on the lpc bus ), an error condition is flagged internally , and the transaction will be completed when the access prevention is removed or when the error handling scheme changes . write operations in this case are ignored and only flagged as an error . this scheme is used upon reset , when access to the boot block data or any other data is not enabled yet and needs some more ec activity . on the other hand , the host does not have the code to handle any error conditions . the next option for the heres field is “ zero one ” (“ 01 ”), which defines “ return 00h on reads and ignore write operations .” this option is used to prevent the host from getting stuck due to an access to data that is protected from read by the host . in this case the host will receive a fixed data ( for example , 00h ) that will allow the memory transaction to complete . write transactions are completed from the host perspective , an error is flagged but the data written is ignored . the third option for heres is “ one zero ” (“ 10 ”), which defines “ return error sync for both reads and writes .” in this option an error indication is sent back to the host as an erroneous termination of the transaction ( for example , using the lpc “ error sync ” response ). this allows error handling software on the host to trap the software that causes the violation and handle it . in parallel an indication of the violation is sent to ec 100 . it should be noted that once read or write access is allowed the access itself may be deferred due to arbitration over the ec core bus . in such a case the host transaction is extended or a busy flag is kept set ( for writes ), but no error is flagged and the transaction is completed normally . the hlock bit ( bit 5 of the smccst register ) is used to enable write operation of the host to the fm . this is required since write operations to the fm are usually non - atomic operations . thus the bus arbitration scheme is not sufficient to prevent mixing the host operations and the ec operations to the same fm device . when cleared , host write accesses to the shared memory are treated as an error , regardless of the access protection settings . after the ec has determined that the host may write to the memory ( the mechanism for that will be discussed later on ), it configures its software in a way that will not access the fm device ( for example , by executing code from a different fm device or ram ), then ec 100 sets the hlock bit enabling the host access to the fm . lastly , ec 100 indicates the completion of this process to host 101 . before ec 100 performs update to the flash , it should prevent host 101 from accessing it through the use of the access override bits , and / or communicate the update to host 101 to prevent it from reading the area and getting erroneous information . additionally , once host 101 completes the write operations to the fm it should produce an indication to ec 100 so that ec 100 can clear the hlock bit . for some of the operations above , a signaling interface between ec 100 and host 101 is required . there are various ways to implement it . an example of such an interface is the ec interface defined in the acpi standard . an alternative to that , which may involve less software overhead on ec 100 ( mainly since it is dedicated to this function ) is the signaling mechanism described herein . fig6 schematically illustrates the signaling interface of an advantageous embodiment of the invention . the signaling interface comprises the shared memory host semaphore register ( smhsem ) 605 depicted in fig3 d . the smhsem register consists of the ec &# 39 ; s semaphore bits , csem 0 – csem 3601 , and the host &# 39 ; s semaphore bits , hsem 0 – hsem 3602 . both ec 100 and host 101 may read the content of the smhsem register . the csem bits 601 of the smhsem register are enabled for ec writes , and may be only read by host 101 ( read only ). on the other hand , host 101 is able to write to the hsem bits 602 , but ec 100 may only read them ( read only ) a write operation by host 101 sets the “ host semaphore write ” ( hsemw ) flag 603 in the smccst register ( fig3 c ). if enabled ( by setting the hsemie bit ( bit 7 ) in the smccst register ), an interrupt is sent to ec 100 to indicate a host semaphore write . if interrupts are not used , ec 100 should use a polling scheme to monitor for host semaphore changes . single bits may be used for indicating various requests or state changes . for example , host 101 may use one of the hsem bits 602 to signal a request to write to the flash . ec 100 will use one of csem bits 601 ( noted here as the “ grant ” flag ) to signal that the bus is granted and the hlock is set , then host 101 will clear its bit when the write is completed . in response , ec 100 will clear the grant flag just before releasing the hlock . after reset , ec 100 has control over the fm , and host 101 may access at most host boot block 122 . it is possible that no memory is accessible by host 101 until proper configurations are done and then host access to the boot block is enabled . it is important to enable update of parts of the ec &# 39 ; s code , constant data , and some host code and potentially other information stored in the fm . the update of this information may be done by ec 100 or by host 101 . in many cases , such as a bios update operation , it is customary and convenient to do this operation using the host . it is a purpose of the present invention to protect this update operation in a way that will reduce the damage in case malicious update operations occur . the first step for this protection is to identify the host update routine . this is done by asking for various identification information from the host , through electronic signatures . another assumption is that the updated information is signed using an electronic signature . a key that allows verifying this signature is stored in the fm in a protected way . the means for electronic signature and identification are well known in the art . examples of algorithms used for this are the rsa public - private key identification and signing algorithms or the sha - 1 hashing algorithm used for generation of a “ summary ” of a document . it is also assumed that either the fm is normally write protected and a flag is set ( in part of the fm that is not accessible to the host ) to indicate when the flash contents may not be valid since the write protect was removed to enable update , and the fm is checked for validity ( as illustrated in fig8 ) when this flag is set . or that the verification is done on every re - start of the ec , as if the flag test showed that it is invalid . it should be noted that the flash contents may be signed ( digital signature ) as one piece or in parts to allow partial updates of the flash . the flow charts provided herein are an example of a way to use the hardware described to implement a secured fm contents update by the host . the protection here takes the form of preventing execution ( read ) from invalid fm contents , and falling into an fm update recovery routine . another way to securely store information in the fm is to pass the infonation between ec 100 and host 101 through a communication channel ( such as the acpi ec channel ) and let ec 100 store the information in the fm at the designated locations ). fig9 illustrates a flow chart that describes a process that is used for updating the flash protected areas by host 101 . typically , ec 100 will be executing its code as host 101 issues a request to gain control over the fm device and to start updating the fm . the host &# 39 ; s update process is initiated in step 920 , and the ec &# 39 ; s update process in step 900 . before any update can take place , in step 921 host 101 provides ec 100 the “ update data ” accompanied by the digital signature on line 955 . when host 101 completes transmission of the “ update data ” and digital signature , it enters a wait state in step 922 , in which the update procedure is halted until the ec &# 39 ; s test results are received on line 950 or line 951 . ec 100 receives the “ update data ” and digital signature in step 910 , and performs a validation test utilizing the digital signature . if it is found in step 911 that the “ update data ” is invalid , in step 912 ec 100 produces an error message and signals to host 101 an error indication on line 950 . ec 100 then exits the update procedure , as the control passes to step 913 . if it is determined in step 911 that the “ update data ” is valid , the control passes to block 901 in which ec 100 enters a “ no fm access ” state in which the ec activities concerning the fm are avoided , additionally ec 100 also sets the “ flash touched / untouched ” flags ( not shown ). the “ flash touched / untouched ” flags are part of the fm and are located in a section enabled for ec read and write operations , and possibly ( but this is not a must ) for host read operations . the bit may be maintained as a single bit or as part of a “ flash file system ” that maintains the flag and potentially other related information in a way that reduces the number of erase operations performed ( various flash file systems are known in the art and may be used ). the operation proceeds in step 902 , in which ec 100 sets the hlock bit in the smccst register , thereby enabling host &# 39 ; s read , erase , and program permissions , and making host update possible . in step 902 ec 100 also produces an indication on line 951 , to signal to host 101 that the “ update data ” is valid and that the update process may proceed . host 101 exits its wait state ( step 922 ), when an indication concerning the “ update data ” validation is received on line 950 or line 951 . when the validation is received , host 101 determines how to proceed in step 913 . if an “ invalid ” indication is received ( i . e ., “ error ” indication on line 950 ), the host update process is terminated as the control passes to step 924 . if a “ valid ” indication is received ( i . e ., “ ok ” indication on line 951 ), the procedure proceeds in step 925 where the update is actually performed . in the next step , step 926 , when the update is complete , host 101 sends to ec 100 an “ end ” indication on line 956 to enable it to proceed . ec 100 exits the “ no fm access ” state when the “ end ” indication is received on line 956 . then , in step 905 , ec 100 determines if there were any attempts by host 101 to access restricted sections , by checking the hrerr and hwerr flags in the smccst register . the check in step 905 may be done in parallel to performing the update in step 925 or at its completion . the ec control may poll the status bits ( hrerr and hwerr ), or use interrupts , when the herrien bit is set . if host 101 did not try to access restricted sections the process continues as the control is passed to step 903 , where ec 100 disables any further host accesses and thereby completes the host &# 39 ; s fm operation . the operation proceeds in step 904 , where ec 100 acknowledges the completion of the update process to host 101 , on line 953 , and clears the hlock flag to cancel the host &# 39 ; s access permissions that where granted for the update process . performing a soft reset in step 830 that re - initializes both ec 100 and host 101 completes the operation . on the other hand , if the hrerr flag or hwerr flag is set ( in step 905 ), due to host attempts to access a restricted section , ec 100 is alerted to handle the misbehavior by host 101 in steps 906 and 907 . ec 100 is able to determine whether the restricted access attempt was for read or write according to the smccst status bits hwerr and hrerr , and this is determined in step 906 . the hlock is removed in step 907 , disabling any further update operation by host 101 . ec 100 reports the error to host 101 , by producing an “ error ” indication on line 952 , then the ec &# 39 ; s update process is stopped . at this point the flash content is invalid and a recovery scheme will be enabled as part of the next boot sequence initiated in step 830 . the boot sequence is started by re - starting ec 100 and host 101 , a procedure that will be later discussed in detail . the completion of the host &# 39 ; s update process depends on the indication it receives from ec 100 regarding the status of the hrerr flag or hwerr flag . in step 927 , it is determined whether the update process was successful or defective . a successful process will be determined when a “ successful ” indication is received from ec 100 on line 953 . in such a case , host 101 produces a message indicating successful completion of the update process in step 929 , and the update process is terminated as the control passes to step 810 , in which the host operation is re - started ( host reset ). if an “ error ” indication is received by host 101 on line 952 , it produces an error message in step 928 , and the update process is also terminated in step 810 ( host reset ). changes to the bios content may be performed when a bios update is required , or new hardware configuration settings need to be applied . bios changes will usually be followed by a system boot operation . a full system boot operation is not mandatory in all cases . when the update is limited in its scope , verification of its correctness before enabling host read from that area might be sufficient . the system start - up according to an advantageous embodiment of the invention consists of bios validity tests , which are performed before the system can enter its normal boot operation sequence . in fig8 , the start - up operation sequence of host 101 and ec 100 is illustrated in the form of a flow chart . the host boot operation sequence starts at step 810 , wherein the boot operation sequence is initiated . in general , host reads and writes are completely disabled after boot operation or update . however , to enable the host boot operation , read permission of host boot block 122 is enabled at step 811 , and then host 101 will read this information to start the boot operation process ( in many cases a de - compress of the boot code from flash to ram is done ). the boot operation continues in step 812 , in which host 101 performs basic initializations . the basic initializations consist of establishing communication with ec 100 and entering a wait loop , at step 813 , in which the host processor awaits a special signal ( for example , using the signaling interface ) from ec 100 that confirms the validity of the bios content for further processing . alternatively , the wait may be implemented using the “ not ready ” indication on the bus imposed when reads are disabled , as described previously . the steps just described herein ( i . e ., starting the boot operation sequence on step 810 , and entering a wait state on step 813 ) are programmed at the factory , and are write protected by definition ( i . e ., not subject to alterations ). parallel to the host &# 39 ; s boot sequence , the ec boot operation sequence takes place , starting at step 830 , wherein the ec boot operation sequence is initiated . in step 831 an update test is performed by ec 100 . this is carried out by testing the “ flash touched / untouched ” flag . an update process is initiated if the flag is set by moving into step 832 . this happens whenever an update process was started prior to the current startup . if the “ flash touched / untouched ” flag indicates that no update took place , control passes to step 836 , in which ec 100 enables the host bios read and sends to host 101 a “ no problem ” indication on line 850 that permits continuation of the host &# 39 ; s boot operation process . in the event of a “ flash touched / untouched ” indication ( i . e ., the “ flash touched / untouched ” flag is “ on ”), control passes to step 832 , in which a bios validity test is performed by checking if the fm contents match the expected signatures . the validity test is of crucial importance when alterations of the bios content are performed , since it enables recovery from malicious attacks and erroneous alterations of the device content . assuming that the validity test results are satisfying , control passes to step 833 , wherein the “ flash touched / untouched ” flag is reset , and the operation continues into its normal boot operation sequence through step 836 . as described above , in step 836 , host read permissions are enabled and ec 100 transmits a “ no problem ” indication on line 850 . the ec boot operation sequence is completed as the control passes to step 837 and ec 100 switches to “ normal operation .” if the bios validity test results are not satisfactory , control passes to step 834 wherein a “ problem ” indication is transmitted on line 851 , notifying host 101 that a “ problem ” was detected . the ec boot operation sequence is then terminated as control passes to step 835 , in which ec 100 enters a recovery state . when host 101 receives the validity test results on line 851 or on line 850 , the host &# 39 ; s boot operation sequence proceeds as control passes from step 813 to step 814 . in step 814 , the path in which the boot operation process continues is determined according to the validity test results . assuming that the validity test results are satisfactory , control passes to step 816 , wherein the host read permissions are enabled and the boot operation process continues , as the control passes to step 817 . when results of the bios validity test are unsatisfactory , host 101 enters a recovery state , as control passes to step 815 . when host recovery is completed , the system is restarted , and the update and validity tests are performed again . in fact , this process will take place until the test results ensure that the bios content is valid and normal operation is possible ( i . e ., an infinite loop is established when the bios recovery is not established ). fig5 schematically illustrates the host and ec recovery process . the recovery process is performed after a failure of a bios update attempt , and its main goal is to enable restoration of the system default settings as they were prior to the update attempt , or load a valid update version . host recovery starts at step 510 where the control passes to step 511 in which host 101 provides ec 100 with the recovery update data on line 550 , that identifies the validity of the update package . when the recovery update data transmission is concluded , the host processor enters a “ wait ” loop in step 512 , in which it waits for a “ start ” signal on line 551 to begin the update operations . the ec update , which is initiated at step 520 , begins with testing the validity of the received update recovery code on line 550 in step 521 . if the recovery update data is found to be invalid in step 522 , boot operation of ec 100 and host 101 is performed in step 526 . if the recovery update data is found to be valid , the control passes to step 523 , in which the flash update procedure is performed as described in fig9 . as part of it , ec 100 enables the fm bios host write permission and a “ start ” signal on line 551 is produced to instruct host 101 to start its update operations in step 513 . when the update is completed , control is passed to step 524 , in which ec 100 enters a “ wait ” state until the host update operations are concluded with the “ end ” signal on line 552 . then a boot operation of both ec 100 and host 101 is performed in step 525 and step 514 , respectively . the validity test is a powerful mean of ensuring that the designated code is original , and that it is received correctly with no alterations . the validity test is based on a “ summary ” of the code generated by a hashing algorithm and an electronic signature generated by a public - key cryptography method . the electronic signature of the designated code is utilized to guarantee the integrity of the code , as guaranteed by the vendor who created the code and signed it . as understood by those skilled in the art , one way of handling these are two unique keys , a private key and a public key , utilized for encryption and decryption of the code &# 39 ; s electronic signature . full comprehension of the key cryptography and the hash functioning is not germane to an understanding of this invention . however , as will be appreciated by those skilled in the art , even the change of a single bit state in the designated update data will be reflected by the hash function product , so that a different “ fingerprint ” will be produced and the validation test will result in fingerprints that do not match . updates to fm read protected sections may be required as well from time to time , for example , to update a cryptography key . in such cases , it is required to enable host write access to a restricted area of the fm read protected section . in such cases , host 101 will be granted the write access only after an identification procedure , but will not be granted read access . this will allow updating specific sections and utilizing an automatic write validation check that the write is successful , but not reading other information that may be in that same section . another option is to provide to ec 100 the data required for an update , and allow ec 100 to perform the write securely . alternatively , read operations may be performed by a procedure in which the host issues an information request for the required information , and access permission is attached to the information request . then ec 100 will provide the required information , thereby ensuring a secured fm content reads . the above examples and descriptions have been provided only for the purpose of illustration , and are not intended to limit the invention in any way . as will be appreciated by the skilled person , the invention can be carried out in a great variety of ways , employing more than one technique from those described above , all without exceeding the scope of the invention .