| /openbmc/openbmc/meta-security/dynamic-layers/meta-perl/recipes-security/bastille/files/ |
| H A D | config | 1 # Q: Would you like to enforce password aging? [Y]
7 # Q: What umask would you like to set for users on the system? [077]
11 # Q: Would you like to deactivate the Apache web server? [Y]
13 # Q: Would you like to password protect single-user mode? [Y]
19 # Q: Would you like to put limits on system resource usage? [N]
21 # Q: Would you like to set more restrictive permissions on the administration utilities? [N]
23 # Q: Would you like to disable SUID status for mount/umount?
25 # Q: Would you like to disable SUID status for ping? [Y]
27 # Q: Would you like to disable SUID status for traceroute? [Y]
33 # Q: Would you like to run the packet filtering script? [N]
[all …]
|
| /openbmc/docs/designs/mctp/ |
| H A D | mctp-userspace.md | 18 For OpenBMC, we would introduce a MCTP daemon, which implements the transport
45 The lower interface would be plugged in to one of a number of hardware-specific
46 binding implementations. Most of these would be included in the library source
52 this, the library would be written in portable C (structured in a way that can
68 socket. Each of these would register with the MCTP daemon to receive MCTP
69 messages of a certain type, and would transmit MCTP messages of that same type.
73 daemon would use a message queue to enable message reception/transmission to a
74 blocked daemon, but this would be of a limited size. Handlers whose sockets
75 exceed this queue would be disconnected from the daemon.
128 disjoint set. This would likely lead to unnecessary restrictions on the
[all …]
|
| /openbmc/u-boot/drivers/usb/eth/ |
| H A D | Kconfig | 4 Say Y here if you would like to enable support for USB Ethernet
13 Say Y here if you would like to support ASIX AX8817X based USB 2.0
20 Say Y here if you would like to support ASIX AX88179 based USB 3.0
28 Say Y here if you would like to support Microchip LAN75XX Hi-Speed
38 Say Y here if you would like to support Microchip LAN78XX USB 3.1
47 Say Y here if you would like to support MOSCHIP MCS7830 based
54 Say Y here if you would like to support Realtek RTL8152B/RTL8153 base
62 Say Y here if you would like to support SMSC LAN95xx based USB 2.0
|
| /openbmc/linux/block/partitions/ |
| D | Kconfig | |
| /openbmc/qemu/docs/system/s390x/ |
| H A D | css.rst | 47 would be ``dev_id = "fe.0.0000"`` and ``subch_id = "fe.0.0000"``.
53 If added to the same Linux guest as above, it would show up as ``0.0.0042``
56 The properties for the device would be ``dev_id = "fe.0.0042"`` and
63 If added to the same Linux guest as above, it would show up as ``0.2.1111``
66 The properties for the device would be ``dev_id = "fe.2.1111"`` and
73 This would not show up in a standard Linux guest.
75 The properties for the device would be ``dev_id = "2.0.2222"`` and
82 This would not show up in a standard Linux guest, either, as ``0`` is not
85 The properties for the device would be ``dev_id = "0.0.1234"`` and
|
| /openbmc/docs/designs/ |
| H A D | thermal-control-modes.md | 51 Initially the current mode would be set to "Default" and the implementation of
52 the interface would populate the supported list of modes.
54 As one implementation, phosphor-fan-presence/control would be updated to extend
55 this dbus interface object which would fill in the list of supported modes from
57 starts, the interface would be added on the zone object and available to be
59 current mode to any of those supported modes and the current mode would be
67 technique would not be reliable in adjusting the floor speeds for only
68 configurations using optical cables. This would instead present the possibility
|
| H A D | psu-monitoring.md | 70 12. The application would periodically communicate with the power supplies via
84 [phosphor-power][6] repository. The application would be written in C++17.
86 Upon startup, the power supply application would be passed a parameter
88 file. This file would contain information such as the D-Bus object name(s),
93 The power supply application would then detect which system type it is running
95 information, what type each supply is, etc. The application would then try to
97 would be considered invalid. The application should continue to check what if
106 The proposed power supply application would not control any fans internal to the
107 power supply, that function would be left to other userspace application(s).
|
| /openbmc/docs/architecture/code-update/ |
| H A D | emmc-storage-design.md | 39 IMAGE_TYPES would need to be created to support a different filesystem type.
89 fairly small chip such as a 32MB one would suffice. Therefore, in order to
90 support two firmware versions, the kernel for each version would need to be
99 kernel images. Selection of the desired kernel image would be done with the
103 additional work would be required to introduce a new method to select the
113 ext4 filesystem, although it is unknown how any of the two would perform in an
116 A suitable alternative would be btrfs, which has checksums for both metadata
138 be needed. Therefore, having an initramfs would offer a more standard
146 rofs-b, and read-write). Additional partitions would be needed for a dual boot
171 works in a similar way, so it would not be complex to implement LVM
[all …]
|
| /openbmc/linux/Documentation/w1/masters/ |
| D | ds2490.rst | |
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/Sensor/ |
| H A D | Accuracy.interface.yaml | 11 ranges. A value of 0.25 would be 0.25%, a value of 2 would represent
12 2%. A value of 2 for 2% would mean that a reading of 10 would have an
|
| /openbmc/linux/tools/memory-model/Documentation/ |
| D | README | |
| /openbmc/linux/Documentation/filesystems/ |
| D | ocfs2-online-filecheck.rst | |
| /openbmc/phosphor-dbus-interfaces/yaml/xyz/openbmc_project/State/ |
| H A D | README.md | 37 A simple system design would be to include a single _BMC_, _Host_, and
45 The _BMC_ would provide interfaces at `/xyz/openbmc_project/state/bmc<instance>`
49 The _Host_ would provide interfaces at
54 The _Chassis_ would provide interfaces at
83 the request would be ambiguous and probably not what the user wanted.
88 multi-chassis system, starting counting from 1 rather than 0 would avoid this
90 chassis. With chassis0 being special, it would allow existing code to continue
93 For example, a system with multiple hosts would have BMCs, Chassis and Hosts
96 them would _not_ be what the API user intended.
|
| /openbmc/linux/Documentation/RCU/ |
| D | UP.rst | |
| /openbmc/linux/Documentation/networking/ |
| D | x25.rst | |
| /openbmc/linux/tools/perf/pmu-events/arch/x86/amdzen3/ |
| D | other.json | |
| /openbmc/linux/Documentation/bpf/ |
| D | ringbuf.rst | |
| /openbmc/openbmc-test-automation/lib/ |
| H A D | boot_utils.robot | 16 # the state that would normally result from
42 # the state that would normally result from
68 # the state that would normally result from
94 # the state that would normally result from
120 # the state that would normally result from
146 # the state that would normally result from
172 # the state that would normally result from
199 # the state that would normally result from
225 # the state that would normally result from
251 # the state that would normally result from
[all …]
|
| /openbmc/linux/Documentation/firmware-guide/acpi/ |
| D | osi.rst | |
| /openbmc/docs/architecture/ |
| H A D | LED-architecture.md | 41 All applicable Inventory D-Bus objects would have a forward association mapping
48 All applicable LED Group D-Bus objects would have an association mapping to
72 used. All applicable Inventory D-Bus objects would have a forward association
79 All applicable LED Group D-Bus objects would have an association mapping to
94 would mean turn ON the LED group `true` would mean turn OFF the LED group
153 In the example, below two URIs would be created:
156 `fault` but do so differently. The lamp_test would also drive a blink signal to
|
| /openbmc/linux/Documentation/scsi/ |
| D | lpfc.rst | |
| /openbmc/linux/Documentation/ |
| D | Kconfig | |
| /openbmc/qemu/docs/devel/ |
| H A D | multi-process.rst | 48 this service would not be able to use this exploit to access files or
51 A QEMU control process would remain, but in multi-process mode, will
52 have no direct interfaces to the VM. During VM execution, it would still
56 from the main QEMU program, which would continue to provide CPU
57 emulation. i.e., the control process would also be the CPU emulation
131 vhost user device, the memory operation would need to be sent over a
203 rest of this section is a discussion of how a proxy object model would
211 QEMU code, because for anything but the simplest device, it would not be
218 processes will provide are specified on its command line, as they would
226 would indicate process *disk-proc* uses a qcow2 emulated disk named
[all …]
|
| /openbmc/linux/Documentation/admin-guide/device-mapper/ |
| D | log-writes.rst | |
| /openbmc/qemu/include/authz/ |
| H A D | pamacct.h | 57 * subsystem. The above config would require a config
59 * lookup it would contain
64 * The external file would then contain a list of usernames.
66 * entry would match the distinguish name:
|