| /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/linux/block/partitions/ |
| H A D | Kconfig | 10 Say Y here if you would like to use hard disks under Linux which
31 Say Y here if you would like to use hard disks under Linux which
44 Say Y here if you would like to use hard disks under Linux which
77 Say Y here if you would like to be able to read the hard disk
89 Say Y here if you would like to use hard disks under Linux which
96 Say Y here if you would like to use hard disks under Linux which
103 Say Y here if you would like to use hard disks under Linux which
110 Say Y here if you would like to be able to read the hard disk
118 Say Y here if you would like to use hard disks under Linux which
182 Say Y here if you would like to use hard disks under Linux which
[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/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/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
172 works in a similar way, so it would not be complex to implement LVM
[all …]
|
| /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/linux/Documentation/filesystems/ |
| H A D | directory-locking.rst | 80 the parent of object and it would have to lock the parent).
113 Otherwise the set of contended objects would be infinite - each of them
114 would have a contended child and we had assumed that no object is its
120 would again have an infinite set of contended objects). But that
131 source), such loop would have to contain these objects and the rest of it
132 would have to exist before rename(). I.e. at the moment of loop creation
133 rename() responsible for that would be holding filesystem lock and new parent
134 would have to be equal to or a descendent of source. But that means that
136 we had acquired filesystem lock and rename() would fail with -ELOOP in that
142 also preserved by all operations (cross-directory rename on a tree that would
[all …]
|
| H A D | ocfs2-online-filecheck.rst | 13 necessary, since turning the filesystem read-only would affect other running
15 Then, a mount option (errors=continue) is introduced, which would return the
34 the offline fsck should/would be recommended.
43 by the inode number which caused the error. This inode number would be the
51 mounted. The file above would accept inode numbers. This could be used to
91 On receiving the inode, the filesystem would read the inode and the
92 file metadata. In case of errors, the filesystem would fix the errors
97 small linked list buffer which would contain the last (N) inodes
|
| /openbmc/linux/Documentation/w1/masters/ |
| H A D | ds2490.rst | 32 was added to the API. The name is just a suggestion. It would take
52 clear the entire bulk in buffer. It would be possible to read the
60 with a OHCI controller, ds2490 running in the guest would operate
64 would fail. qemu sets a 50ms timeout and the bulk in would timeout
65 even when the status shows data available. A bulk out write would
66 show a successful completion, but the ds2490 status register would
68 reattaching would clear the problem. usbmon output in the guest and
|
| /openbmc/linux/drivers/net/wireless/intel/iwlwifi/cfg/ |
| H A D | 22000.c | 189 * HT size; mac80211 would otherwise pick the HE max (256) by default.
225 * HT size; mac80211 would otherwise pick the HE max (256) by default.
238 * HT size; mac80211 would otherwise pick the HE max (256) by default.
251 * HT size; mac80211 would otherwise pick the HE max (256) by default.
263 * HT size; mac80211 would otherwise pick the HE max (256) by default.
276 * HT size; mac80211 would otherwise pick the HE max (256) by default.
289 * HT size; mac80211 would otherwise pick the HE max (256) by default.
301 * HT size; mac80211 would otherwise pick the HE max (256) by default.
315 * HT size; mac80211 would otherwise pick the HE max (256) by default.
328 * HT size; mac80211 would otherwise pick the HE max (256) by default.
[all …]
|
| /openbmc/linux/tools/memory-model/Documentation/ |
| H A D | README | 8 depending on what you know and what you would like to learn. Please note
14 o You have some background in Linux-kernel concurrency, and would
24 o You are familiar with Linux-kernel concurrency, and would
28 o You would like a detailed understanding of what your compiler can
32 LKMM, and would like a quick reference: cheatsheet.txt
35 of LKMM, and would like to learn about LKMM's requirements,
|
| /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/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/ |
| H A D | UP.rst | 26 from softirq, the list scan would find itself referencing a newly freed
47 its arguments would cause it to fail to make the fundamental guarantee
61 call_rcu() were to directly invoke the callback, the result would
65 In some cases, it would possible to restructure to code so that
70 the same critical section, then the code would need to create
82 or API changes would be required.
136 the process-context critical section. This would result in
150 simply immediately returned, it would prematurely signal the
151 end of the grace period, which would come as a nasty shock to
|
| /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/Documentation/bpf/ |
| H A D | ringbuf.rst | 27 would solve the second problem automatically.
36 One way would be to, similar to ``BPF_MAP_TYPE_PERF_EVENT_ARRAY``, make
38 enforce "same CPU only" rule. This would be more familiar interface compatible
39 with existing perf buffer use in BPF, but would fail if application needed more
42 Additionally, given the performance of BPF ringbuf, many use cases would just
44 approach would be an overkill.
48 with lookup/update/delete operations. This approach would add a lot of extra
50 would also add another concept that BPF developers would have to familiarize
51 themselves with, new syntax in libbpf, etc. But then would really provide no
60 ring buffer for all CPUs, it's as simple and straightforward, as would be with
[all …]
|
| /openbmc/linux/Documentation/networking/ |
| H A D | snmp_counter.rst | 44 multicast packets, and would always be updated together with
137 would be increased even if the ICMP packet has an invalid type. The
139 IcmpOutMsgs would still be updated if the IP header is constructed by
207 IcmpMsgOutType8 would increase 1. And if kernel gets an ICMP Echo Reply
208 packet, IcmpMsgInType0 would increase 1.
215 IcmpInMsgs would be updated but none of IcmpMsgInType[N] would be updated.
225 counters would be updated. The receiving packet path use IcmpInErrors
227 is increased, IcmpInErrors would always be increased too.
263 packets would be delivered to the TCP layer, but the TCP layer will discard
266 counter would only increase 1.
[all …]
|
| H A D | x25.rst | 18 implementation of LAPB. Therefore the LAPB modules would be called by
19 unintelligent X.25 card drivers and not by intelligent ones, this would
24 conform with the JNT "Pink Book", this would have a different interface to
25 the Packet Layer but there would be no confusion since the class of device
26 being served by the LLC would be completely separate from LAPB.
|
| /openbmc/linux/Documentation/firmware-guide/acpi/ |
| H A D | osi.rst | 70 The ACPI BIOS flow would include an evaluation of _OS, and the AML
71 interpreter in the kernel would return to it a string identifying the OS:
83 of every possible version of the OS that would run on it, and needed to know
84 all the quirks of those OS's. Certainly it would make more sense
91 that anybody would install those old operating systems
104 eg. _OSI("3.0 Thermal Model") would return TRUE if the OS knows how
106 An old OS that doesn't know about those extensions would answer FALSE,
121 and its successors. To do otherwise would virtually guarantee breaking
156 which would increment, based on the version of the spec supported.
158 Unfortunately, _REV was also misused. eg. some BIOS would check
|
| /openbmc/linux/tools/perf/pmu-events/arch/x86/amdzen3/ |
| H A D | other.json | 22 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
28 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
34 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
40 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
52 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
58 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
64 …Stall. Also counts cycles when the thread is not selected to dispatch but would have been stalled …
|
| /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/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/ |
| H A D | lpfc.rst | 36 the LLDD would simply be queued for a short duration, allowing the device
38 to the system. If the driver did not hide these conditions, i/o would be
39 errored by the driver, the mid-layer would exhaust its retries, and the
40 device would be taken offline. Manual intervention would be required to
|