Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: A plurality of pages of code executing via a container host operating system are monitored. The plurality of pages of code include pages of code from a plurality of container applications configured to utilize the container host operating system. A determination is made that a page of code of the plurality of pages of code violates a security policy configured to apply security within the container host operating system. A container application of the plurality of container applications is identified as a source of the page of code of the plurality of pages of code. The security policy is applied to the container application of the plurality of container applications in response to identifying the container application of the plurality of container applications as the source of the page of code.

Abstract: A plurality of pages of code executing via a container host operating system are monitored. The plurality of pages of code include pages of code from a plurality of container applications configured to utilize the container host operating system. A determination is made that a page of code of the plurality of pages of code violates a security policy configured to apply security within the container host operating system. A container application of the plurality of container applications is identified as a source of the page of code of the plurality of pages of code. The security policy is applied to the container application of the plurality of container applications in response to identifying the container application of the plurality of container applications as the source of the page of code.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: Techniques are provided for actively managing secure boot variables. Such techniques include receiving a request from an entity to modify a portion of a basic input/output system (BIOS), the request including a data segment, and verifying that the requesting entity is authorized to modify a portion of the BIOS. In response to verifying that the requesting entity is authorized, the portion of the BIOS is modified based on the received request and the data segment, and a copy of the data segment is stored in a file on a physical memory that is communicatively coupled to the BIOS. If the BIOS is updated, thereby erasing part or all of the secure boot variables that are stored in the BIOS, the record of changes of the secure boot variables along with default authenticated variables may be used to restore the secure boot variables to a state prior to the BIOS update.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: A method is provided in one example embodiment that includes storing a reference measurement of an object in a trusted storage and retrieving the reference measurement from the trusted storage before an operating system is loaded. In a pre-operating system environment, the reference measurement can be compared with a golden measurement and a policy action can be applied if a variance is detected between the reference measurement and the golden measurement. In more particular embodiments, the reference measurement is a measurement of firmware, and yet more particularly, the measurement is a hash of the firmware.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: Techniques are provided for actively managing secure boot variables. Such techniques include receiving a request from an entity to modify a portion of a basic input/output system (BIOS), the request including a data segment, and verifying that the requesting entity is authorized to modify a portion of the BIOS. In response to verifying that the requesting entity is authorized, the portion of the BIOS is modified based on the received request and the data segment, and a copy of the data segment is stored in a file on a physical memory that is communicatively coupled to the BIOS. If the BIOS is updated, thereby erasing part or all of the secure boot variables that are stored in the BIOS, the record of changes of the secure boot variables along with default authenticated variables may be used to restore the secure boot variables to a state prior to the BIOS update.

Abstract: A method is provided in one example embodiment and includes storing secure boot variables in a baseboard management controller; and sending the secure boot variables to a basic input/output system (BIOS) during a power on self-test, where the BIOS utilizes the secure boot variables during runtime to authenticate drivers and an operating system loader execution. In particular embodiments, the secure boot variables may be included in a white list, a black list, or a key list and, further, stored in erasable programmable read only memory.

Abstract: A method is provided in one example embodiment that includes storing a reference measurement of an object in a trusted storage and retrieving the reference measurement from the trusted storage before an operating system is loaded. In a pre-operating system environment, the reference measurement can be compared with a golden measurement and a policy action can be applied if a variance is detected between the reference measurement and the golden measurement. In more particular embodiments, the reference measurement is a measurement of firmware, and yet more particularly, the measurement is a hash of the firmware.

Abstract: Techniques are provided for authenticating a user when accessing a Basic Input/Output System (BIOS) of a computing device. Access request information is received. An access information database is queried to authenticate the access request information with access information stored in the access information database. Validation information is received, indicating whether the access request information is authenticated, and permission is granted for access to settings of the computing device if the validation information indicates that the access request information is authenticated.

Abstract: An RJ 11 port is disclosed that detects the device to which it is connected and automatically reconfigures itself as end user equipment or network interface equipment.

Abstract: A portable computer case whether in a closed state or open state permits a user to exercise control and monitor certain operating features. The user may toggle a control switch to place the computer system in a secondary operational mode, determine when a computer system is in a secondary operational mode, and adjust a digital master volume control during the secondary operational mode. The portable computer system includes a status indicator for indicating when a computer is in a secondary operational mode, digital master volume control buttons operable in a secondary operational mode, and a control switch for placing the computer system in a secondary operational mode. The status indicator, volume control buttons, and control switch are preferably provided on a top surface of the bottom shell of the portable computer for convenient access by a user.

Abstract: A method of interfacing telephone data with a computer system that includes a computer TDM bus. The method includes receiving the telephone data from a plurality of telephony codecs over a telephony bus. The telephony data includes a plurality of telephony time slots. The method further includes multiplexing the plurality of telephony slots into at least one computer bus time slot and transmitting the at least one computer bus time slot over the computer time division multiplexed bus.

Abstract: Briefly, a computer system plays audio CDs in a CD-ROM drive during an audio CD play mode in which the computer system is not fully powered. An audio CD play controller of the computer system includes a means for detecting a plurality of audio CD play buttons for playing an audio CD in the CD-ROM drive and a means for communicating a plurality of audio CD play commands corresponding to the plurality of audio CD play buttons to the CD-ROM drive. The computer system enters the audio CD play mode without a full boot-up procedure and without loading an operating system.

Abstract: A portable computer case whether in a closed state or open state permits a user to exercise control and monitor certain operating features. The user may toggle a control switch to place the computer system in a secondary operational mode, determine when a computer system is in a secondary operational mode, and adjust a digital master volume control during the secondary operational mode. The portable computer system includes a status indicator for indicating when a computer is in a secondary operational mode, digital master volume control buttons operable in a secondary operational mode, and a control switch for placing the computer system in a secondary operational mode. The status indicator, volume control buttons, and control switch are preferably provided on a top surface of the bottom shell of the portable computer for convenient access by a user.